Consistently use read-only instead of "read only"

This affects one message and some documentation that used the format
"read only", unlike everything else that used read-only.

Backpatch-through: 14
Discussion: https://postgr.es/m/CABUevExuxKwn0YM3+wdSeQSvK6CRrJ-hewocGVX3R4-xVX4eMw@mail.gmail.com

4 files changed, 11 insertions, 11 deletions

diff --git a/doc/src/sgml/catalogs.sgml b/doc/src/sgml/catalogs.sgml
index 2b2c70a26e5..2f0def9b19a 100644
--- a/doc/src/sgml/catalogs.sgml
+++ b/doc/src/sgml/catalogs.sgml
@@ -9602,7 +9602,7 @@ SCRAM-SHA-256$<replaceable>&lt;iteration count&gt;</replaceable>:<replaceable>&l
   </table>
 
   <para>
-   The <structname>pg_available_extensions</structname> view is read only.
+   The <structname>pg_available_extensions</structname> view is read-only.
   </para>
  </sect1>
 
@@ -9726,8 +9726,8 @@ SCRAM-SHA-256$<replaceable>&lt;iteration count&gt;</replaceable>:<replaceable>&l
   </table>
 
   <para>
-   The <structname>pg_available_extension_versions</structname> view is read
-   only.
+   The <structname>pg_available_extension_versions</structname> view is
+   read-only.
   </para>
  </sect1>
 
@@ -10042,7 +10042,7 @@ SCRAM-SHA-256$<replaceable>&lt;iteration count&gt;</replaceable>:<replaceable>&l
   </table>
 
   <para>
-   The <structname>pg_cursors</structname> view is read only.
+   The <structname>pg_cursors</structname> view is read-only.
   </para>
 
  </sect1>
@@ -11164,7 +11164,7 @@ SELECT * FROM pg_locks pl LEFT JOIN pg_prepared_xacts ppx
   </table>
 
   <para>
-   The <structname>pg_prepared_statements</structname> view is read only.
+   The <structname>pg_prepared_statements</structname> view is read-only.
   </para>
  </sect1>
 
diff --git a/doc/src/sgml/high-availability.sgml b/doc/src/sgml/high-availability.sgml
index 22af7dbf51b..c43f2140205 100644
--- a/doc/src/sgml/high-availability.sgml
+++ b/doc/src/sgml/high-availability.sgml
@@ -1093,7 +1093,7 @@ primary_slot_name = 'node_a_slot'
    </para>
 
    <para>
-    Read only transactions and transaction rollbacks need not wait for
+    Read-only transactions and transaction rollbacks need not wait for
     replies from standby servers. Subtransaction commits do not wait for
     responses from standby servers, only top-level commits. Long
     running actions such as data loading or index building do not wait
@@ -1962,7 +1962,7 @@ LOG:  entering standby mode
 ... then some time later ...
 
 LOG:  consistent recovery state reached
-LOG:  database system is ready to accept read only connections
+LOG:  database system is ready to accept read-only connections
 </programlisting>
 
     Consistency information is recorded once per checkpoint on the primary.
@@ -2191,7 +2191,7 @@ HINT:  You can then restart the server after making the necessary configuration
    </para>
 
    <para>
-    Currently, temporary table creation is not allowed during read only
+    Currently, temporary table creation is not allowed during read-only
     transactions, so in some cases existing scripts will not run correctly.
     This restriction might be relaxed in a later release. This is
     both an SQL Standard compliance issue and a technical issue.
@@ -2290,7 +2290,7 @@ HINT:  You can then restart the server after making the necessary configuration
     <para>
      Full knowledge of running transactions is required before snapshots
      can be taken. Transactions that use large numbers of subtransactions
-     (currently greater than 64) will delay the start of read only
+     (currently greater than 64) will delay the start of read-only
      connections until the completion of the longest running write transaction.
      If this situation occurs, explanatory messages will be sent to the server log.
     </para>
diff --git a/doc/src/sgml/mvcc.sgml b/doc/src/sgml/mvcc.sgml
index d358bbe4a6a..cfdcb74221a 100644
--- a/doc/src/sgml/mvcc.sgml
+++ b/doc/src/sgml/mvcc.sgml
@@ -526,7 +526,7 @@ ERROR:  could not serialize access due to concurrent update
     transaction sees a completely stable view of the database.  However,
     this view will not necessarily always be consistent with some serial
     (one at a time) execution of concurrent transactions of the same level.
-    For example, even a read only transaction at this level may see a
+    For example, even a read-only transaction at this level may see a
     control record updated to show that a batch has been completed but
     <emphasis>not</emphasis> see one of the detail records which is logically
     part of the batch because it read an earlier revision of the control
diff --git a/src/backend/postmaster/postmaster.c b/src/backend/postmaster/postmaster.c
index 9c2c98614aa..63043ed8d1f 100644
--- a/src/backend/postmaster/postmaster.c
+++ b/src/backend/postmaster/postmaster.c
@@ -5199,7 +5199,7 @@ sigusr1_handler(SIGNAL_ARGS)
 		PgStatPID = pgstat_start();
 
 		ereport(LOG,
-				(errmsg("database system is ready to accept read only connections")));
+				(errmsg("database system is ready to accept read-only connections")));
 
 		/* Report status */
 		AddToDataDirLockFile(LOCK_FILE_LINE_PM_STATUS, PM_STATUS_READY);