doc: Fix some grammar for logical decoding description and functions
authorMichael Paquier <[email protected]>
Fri, 14 Apr 2023 04:08:02 +0000 (13:08 +0900)
committerMichael Paquier <[email protected]>
Fri, 14 Apr 2023 04:08:02 +0000 (13:08 +0900)
This documentation is has been added for the support of logical decoding
on standbys.  Some markups were missing, hence add some where required.

Author: Thom Brown
Reviewed-by: Justin Pryzby, Daniel Gustafsson
Discussion: https://postgr.es/m/CAA-aLv7xCZ0nBJa-NWe0rxBB28TjFjS2JtjiZMoQ+0wsugG+hQ@mail.gmail.com

doc/src/sgml/func.sgml
doc/src/sgml/logicaldecoding.sgml
doc/src/sgml/monitoring.sgml

index e6a7514100e961ce181338978ce41ede58eee8a9..5a47ce4343462ac2cac18d0b291b7c28fe352a75 100644 (file)
@@ -27084,8 +27084,8 @@ postgres=# SELECT '0/0'::pg_lsn + pd.segment_number * ps.setting::int + :offset
        </para>
        <para>
         Take a snapshot of running transactions and write it to WAL, without
-        having to wait bgwriter or checkpointer to log one. This is useful for
-        logical decoding on standby, as logical slot creation has to wait
+        having to wait for bgwriter or checkpointer to log one. This is useful
+        for logical decoding on standby, as logical slot creation has to wait
         until such a record is replayed on the standby.
        </para></entry>
       </row>
index e61059d71e4906499b9adae3c9108f5a29bdccf5..cbd3aa804f77b73e29b61f654a4614bf2ce6f635 100644 (file)
@@ -321,16 +321,18 @@ postgres=# select * from pg_logical_slot_get_changes('regression_slot', NULL, NU
      <command>VACUUM</command> from removing required rows from the system
      catalogs, <varname>hot_standby_feedback</varname> should be set on the
      standby. In spite of that, if any required rows get removed, the slot gets
-     invalidated. It's highly recommended to use a physical slot between the primary
-     and the standby. Otherwise, hot_standby_feedback will work, but only while the
-     connection is alive (for example a node restart would break it). Then, the
-     primary may delete system catalog rows that could be needed by the logical
-     decoding on the standby (as it does not know about the catalog_xmin on the
-     standby). Existing logical slots on standby also get invalidated if wal_level
-     on primary is reduced to less than 'logical'. This is done as soon as the
-     standby detects such a change in the WAL stream. It means, that for walsenders
-     that are lagging (if any), some WAL records up to the wal_level parameter change
-     on the primary won't be decoded.
+     invalidated. It's highly recommended to use a physical slot between the
+     primary and the standby. Otherwise, <varname>hot_standby_feedback</varname>
+     will work but only while the connection is alive (for example a node
+     restart would break it). Then, the primary may delete system catalog rows
+     that could be needed by the logical decoding on the standby (as it does
+     not know about the catalog_xmin on the standby). Existing logical slots
+     on standby also get invalidated if <varname>wal_level</varname> on the
+     primary is reduced to less than <literal>logical</literal>.
+     This is done as soon as the standby detects such a change in the WAL stream.
+     It means that, for walsenders which are lagging (if any), some WAL records up
+     to the <varname>wal_level</varname> parameter change on the primary won't be
+     decoded.
     </para>
 
     <para>
index 0281201745503c4174aa45822c012ca3311b2918..2903b67170c6937d1e79a3e0ba4c79bc3c41bee8 100644 (file)
@@ -4757,7 +4757,7 @@ SELECT pid, wait_event_type, wait_event FROM pg_stat_activity WHERE wait_event i
       </para>
       <para>
        Number of uses of logical slots in this database that have been
-       canceled due to old snapshots or a too low <xref linkend="guc-wal-level"/>
+       canceled due to old snapshots or too low a <xref linkend="guc-wal-level"/>
        on the primary
       </para></entry>
      </row>