mirrors/postgres
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

doc: Fix some grammar for logical decoding description and functions

Browse Source 
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
This commit is contained in:
Michael Paquier 2023-04-14 13:08:02 +09:00
parent 558c9d75fe
commit c7dc56bd6b
3 changed files with 15 additions and 13 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
doc/src/sgml/func.sgml
View 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>

22
doc/src/sgml/logicaldecoding.sgml
View 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>

2
doc/src/sgml/monitoring.sgml
View 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>