Hi, On Fri, Mar 01, 2024 at 03:22:55PM +1100, Peter Smith wrote: > Here are some review comments for v102-0001. > > ====== > doc/src/sgml/config.sgml > > 1. > + <para> > + Lists the streaming replication standby server slot names that > logical > + WAL sender processes will wait for. Logical WAL sender processes will > + send decoded changes to plugins only after the specified replication > + slots confirm receiving WAL. This guarantees that logical replication > + slots with failover enabled do not consume changes until those > changes > + are received and flushed to corresponding physical standbys. If a > + logical replication connection is meant to switch to a physical > standby > + after the standby is promoted, the physical replication slot for the > + standby should be listed here. Note that logical replication will not > + proceed if the slots specified in the standby_slot_names do > not exist or > + are invalidated. > + </para> > > Should this also mention the effect this GUC has on those 2 SQL > functions? E.g. Commit message says: > > Additionally, The SQL functions pg_logical_slot_get_changes and > pg_replication_slot_advance are modified to wait for the replication > slots mentioned in 'standby_slot_names' to catch up before returning.
I think that's also true for all the ones that rely on pg_logical_slot_get_changes_guts(), means: - pg_logical_slot_get_changes - pg_logical_slot_peek_changes - pg_logical_slot_get_binary_changes - pg_logical_slot_peek_binary_changes Not sure it's worth to mention the "binary" ones though as their doc mention they behave as their "non binary" counterpart. Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com
