diff options
Diffstat (limited to 'doc')
| -rw-r--r-- | doc/src/sgml/func.sgml | 4 | ||||
| -rw-r--r-- | doc/src/sgml/logicaldecoding.sgml | 22 | ||||
| -rw-r--r-- | doc/src/sgml/monitoring.sgml | 2 |
3 files changed, 15 insertions, 13 deletions
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml index e6a7514100..5a47ce4343 100644 --- a/doc/src/sgml/func.sgml +++ b/doc/src/sgml/func.sgml @@ -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> diff --git a/doc/src/sgml/logicaldecoding.sgml b/doc/src/sgml/logicaldecoding.sgml index e61059d71e..cbd3aa804f 100644 --- a/doc/src/sgml/logicaldecoding.sgml +++ b/doc/src/sgml/logicaldecoding.sgml @@ -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> diff --git a/doc/src/sgml/monitoring.sgml b/doc/src/sgml/monitoring.sgml index 0281201745..2903b67170 100644 --- a/doc/src/sgml/monitoring.sgml +++ b/doc/src/sgml/monitoring.sgml @@ -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> |