I had a customer point out to me that we're inconsistent in how we
spell read-only. Turns out we're not as inconsistent as I initially
thought :), but that they did manage to spot the one actual log
message we have that writes it differently than everything else -- but
that broke their grepping...
Almost everywhere we use read-only. Attached patch changes the one log
message where we didn't, as well as a few places in the docs for it. I
did not bother with things like comments in the code.
Two questions:
1. Is it worth fixing? Or just silly nitpicking?
2. What about translations? This string exists in translations --
should we just "fix" it there, without touching the translated string?
Or try to fix both? Or leave it for the translators who will get a
diff on it?
--
Magnus Hagander
Me: https://www.hagander.net/
Work: https://www.redpill-linpro.com/
diff --git a/doc/src/sgml/catalogs.sgml b/doc/src/sgml/catalogs.sgml
index 2b2c70a26e..2f0def9b19 100644
--- a/doc/src/sgml/catalogs.sgml
+++ b/doc/src/sgml/catalogs.sgml
@@ -9602,7 +9602,7 @@ SCRAM-SHA-256$<replaceable><iteration count></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><iteration count></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><iteration count></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 22af7dbf51..c43f214020 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 d358bbe4a6..cfdcb74221 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 9c2c98614a..63043ed8d1 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);
