database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-06-13 07:41:39 +03:00
Code Activity

Allow logical decoding on standbys

Browse Source 
Unsurprisingly, this requires wal_level = logical to be set on the primary and
standby. The infrastructure added in 26669757b6 ensures that slots are
invalidated if the primary's wal_level is lowered.

Creating a slot on a standby waits for a xl_running_xact record to be
processed. If the primary is idle (and thus not emitting xl_running_xact
records), that can take a while.  To make that faster, this commit also
introduces the pg_log_standby_snapshot() function. By executing it on the
primary, completion of slot creation on the standby can be accelerated.

Note that logical decoding on a standby does not itself enforce that required
catalog rows are not removed. The user has to use physical replication slots +
hot_standby_feedback or other measures to prevent that. If catalog rows
required for a slot are removed, the slot is invalidated.

See 6af1793954 for an overall design of logical decoding on a standby.

Bumps catversion, for the addition of the pg_log_standby_snapshot() function.

Author: "Drouvot, Bertrand" <bertranddrouvot.pg@gmail.com>
Author: Andres Freund <andres@anarazel.de> (in an older version)
Author: Amit Khandekar <amitdkhan.pg@gmail.com> (in an older version)
Reviewed-by: Andres Freund <andres@anarazel.de>
Reviewed-by: FabrÌzio de Royes Mello <fabriziomello@gmail.com>
Reviewed-by: Amit Kapila <amit.kapila16@gmail.com>
Reviewed-By: Robert Haas <robertmhaas@gmail.com>
This commit is contained in:
Andres Freund
2023-04-08 02:20:01 -07:00
parent e101dfac3a
commit 0fdab27ad6
12 changed files with 203 additions and 62 deletions
Download Patch File Download Diff File Expand all files Collapse all files

15
doc/src/sgml/func.sgml
View File

@ -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>

27
doc/src/sgml/logicaldecoding.sgml
View File

@ -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