diff options
Diffstat (limited to 'doc/src')
| -rw-r--r-- | doc/src/sgml/func.sgml | 15 | ||||
| -rw-r--r-- | doc/src/sgml/logicaldecoding.sgml | 27 |
2 files changed, 42 insertions, 0 deletions
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml index 4211d31f307..bf4c61ccfbd 100644 --- a/doc/src/sgml/func.sgml +++ b/doc/src/sgml/func.sgml @@ -27074,6 +27074,21 @@ postgres=# SELECT '0/0'::pg_lsn + pd.segment_number * ps.setting::int + :offset prepared with <xref linkend="sql-prepare-transaction"/>. </para></entry> </row> + <row> + <entry role="func_table_entry"><para role="func_signature"> + <indexterm> + <primary>pg_log_standby_snapshot</primary> + </indexterm> + <function>pg_log_standby_snapshot</function> () + <returnvalue>pg_lsn</returnvalue> + </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 + until such a record is replayed on the standby. + </para></entry> + </row> </tbody> </tgroup> </table> diff --git a/doc/src/sgml/logicaldecoding.sgml b/doc/src/sgml/logicaldecoding.sgml index 4e912b4bd48..ebe0376e3e6 100644 --- a/doc/src/sgml/logicaldecoding.sgml +++ b/doc/src/sgml/logicaldecoding.sgml @@ -316,6 +316,33 @@ postgres=# select * from pg_logical_slot_get_changes('regression_slot', NULL, NU may consume changes from a slot at any given time. </para> + <para> + A logical replication slot can also be created on a hot standby. To prevent + <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. + </para> + + <para> + Creation of a logical slot requires information about all the currently + running transactions. On the primary, this information is available + directly, but on a standby, this information has to be obtained from + primary. Thus, slot creation may need to wait for some activity to happen + on the primary. If the primary is idle, creating a logical slot on + standby may take noticeable time. This can be sped up by calling the + <function>pg_log_standby_snapshot</function> on the primary. + </para> + <caution> <para> Replication slots persist across crashes and know nothing about the state |