public inbox for [email protected]help / color / mirror / Atom feed
Placement of synchronized_standby_slots description in config.sgml 3+ messages / 2 participants [nested] [flat]
* Placement of synchronized_standby_slots description in config.sgml @ 2026-01-23 10:21 Fujii Masao <[email protected]> 2026-02-05 06:47 ` Re: Placement of synchronized_standby_slots description in config.sgml Shinya Kato <[email protected]> 0 siblings, 1 reply; 3+ messages in thread From: Fujii Masao @ 2026-01-23 10:21 UTC (permalink / raw) To: [email protected] Hi, synchronized_standby_slots is defined in guc_parameter.dat as part of the REPLICATION_PRIMARY group and appears under the "Primary Server" section in postgresql.conf.sample. However, in the documentation its description is placed under the "Sending Servers" section. Given this, it seems the description should also be under "Primary Server" in the documentation. I've attached a patch that moves it there. Alternatively, if synchronized_standby_slots is intended to be set also on a standby in cascading replication setups, then the current documentation placement may be correct, and instead guc_parameter.dat and postgresql.conf.sample should be updated. My understanding, though, is that this parameter is normally set only on the primary. Right? Regards, -- Fujii Masao Attachments: [application/octet-stream] v1-0001-doc-Move-synchronized_standby_slots-to-Primary-Se.patch (5.6K, ../../CAHGQGwE_LwgXgCrqd08OFteJqdERiF3noqOKu2vt7Kjk4vMiGg@mail.gmail.com/2-v1-0001-doc-Move-synchronized_standby_slots-to-Primary-Se.patch) download | inline diff: From ac42540c4adf870afab620ec09dfd76b6a8bb5a9 Mon Sep 17 00:00:00 2001 From: Fujii Masao <[email protected]> Date: Fri, 23 Jan 2026 16:51:31 +0900 Subject: [PATCH v1] doc: Move synchronized_standby_slots to Primary Server section. synchronized_standby_slots is defined in guc_parameter.dat as part of the REPLICATION_PRIMARY group and is listed under the "Primary Server" section in postgresql.conf.sample. However, in the documentation its description was previously placed under the "Sending Servers" section. This commit moves the description of synchronized_standby_slots to the "Primary Server" section in the documentation. --- doc/src/sgml/config.sgml | 78 ++++++++++++++++++++-------------------- 1 file changed, 39 insertions(+), 39 deletions(-) diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml index 5560b95ee60..0cacc062cdd 100644 --- a/doc/src/sgml/config.sgml +++ b/doc/src/sgml/config.sgml @@ -4722,45 +4722,6 @@ restore_command = 'copy "C:\\server\\archivedir\\%f" "%p"' # Windows </listitem> </varlistentry> - <varlistentry id="guc-synchronized-standby-slots" xreflabel="synchronized_standby_slots"> - <term><varname>synchronized_standby_slots</varname> (<type>string</type>) - <indexterm> - <primary><varname>synchronized_standby_slots</varname> configuration parameter</primary> - </indexterm> - </term> - <listitem> - <para> - A comma-separated list of 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 - failover slots 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 - <varname>synchronized_standby_slots</varname> do not exist or are invalidated. - Additionally, the replication management functions - <link linkend="pg-replication-slot-advance"> - <function>pg_replication_slot_advance</function></link>, - <link linkend="pg-logical-slot-get-changes"> - <function>pg_logical_slot_get_changes</function></link>, and - <link linkend="pg-logical-slot-peek-changes"> - <function>pg_logical_slot_peek_changes</function></link>, - when used with logical failover slots, will block until all - physical slots specified in <varname>synchronized_standby_slots</varname> have - confirmed WAL receipt. - </para> - <para> - The standbys corresponding to the physical replication slots in - <varname>synchronized_standby_slots</varname> must configure - <literal>sync_replication_slots = true</literal> so they can receive - logical failover slot changes from the primary. - </para> - </listitem> - </varlistentry> - </variablelist> </sect2> @@ -4909,6 +4870,45 @@ ANY <replaceable class="parameter">num_sync</replaceable> ( <replaceable class=" file or on the server command line. </para> </listitem> + + </varlistentry> + <varlistentry id="guc-synchronized-standby-slots" xreflabel="synchronized_standby_slots"> + <term><varname>synchronized_standby_slots</varname> (<type>string</type>) + <indexterm> + <primary><varname>synchronized_standby_slots</varname> configuration parameter</primary> + </indexterm> + </term> + <listitem> + <para> + A comma-separated list of 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 + failover slots 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 + <varname>synchronized_standby_slots</varname> do not exist or are invalidated. + Additionally, the replication management functions + <link linkend="pg-replication-slot-advance"> + <function>pg_replication_slot_advance</function></link>, + <link linkend="pg-logical-slot-get-changes"> + <function>pg_logical_slot_get_changes</function></link>, and + <link linkend="pg-logical-slot-peek-changes"> + <function>pg_logical_slot_peek_changes</function></link>, + when used with logical failover slots, will block until all + physical slots specified in <varname>synchronized_standby_slots</varname> have + confirmed WAL receipt. + </para> + <para> + The standbys corresponding to the physical replication slots in + <varname>synchronized_standby_slots</varname> must configure + <literal>sync_replication_slots = true</literal> so they can receive + logical failover slot changes from the primary. + </para> + </listitem> </varlistentry> </variablelist> -- 2.51.2 ^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: Placement of synchronized_standby_slots description in config.sgml 2026-01-23 10:21 Placement of synchronized_standby_slots description in config.sgml Fujii Masao <[email protected]> @ 2026-02-05 06:47 ` Shinya Kato <[email protected]> 2026-02-06 00:43 ` Re: Placement of synchronized_standby_slots description in config.sgml Fujii Masao <[email protected]> 0 siblings, 1 reply; 3+ messages in thread From: Shinya Kato @ 2026-02-05 06:47 UTC (permalink / raw) To: Fujii Masao <[email protected]>; +Cc: [email protected] On Fri, Jan 23, 2026 at 7:22 PM Fujii Masao <[email protected]> wrote: > > Hi, > > synchronized_standby_slots is defined in guc_parameter.dat as part of > the REPLICATION_PRIMARY group and appears under the "Primary Server" > section in postgresql.conf.sample. However, in the documentation > its description is placed under the "Sending Servers" section. > > Given this, it seems the description should also be under "Primary Server" > in the documentation. I've attached a patch that moves it there. Thank you for the patch! The patch LGTM. > Alternatively, if synchronized_standby_slots is intended to be set also > on a standby in cascading replication setups, then the current documentation > placement may be correct, and instead guc_parameter.dat and > postgresql.conf.sample should be updated. My understanding, though, > is that this parameter is normally set only on the primary. Right? You're right. PhysicalWakeupLogicalWalSnd() in walsender.c has this check: /* * If we are running in a standby, there is no need to wake up walsenders. * This is because we do not support syncing slots to cascading standbys, * so, there are no walsenders waiting for standbys to catch up. */ if (RecoveryInProgress()) return; So this parameter is only meaningful on the primary. -- Best regards, Shinya Kato NTT OSS Center ^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: Placement of synchronized_standby_slots description in config.sgml 2026-01-23 10:21 Placement of synchronized_standby_slots description in config.sgml Fujii Masao <[email protected]> 2026-02-05 06:47 ` Re: Placement of synchronized_standby_slots description in config.sgml Shinya Kato <[email protected]> @ 2026-02-06 00:43 ` Fujii Masao <[email protected]> 0 siblings, 0 replies; 3+ messages in thread From: Fujii Masao @ 2026-02-06 00:43 UTC (permalink / raw) To: Shinya Kato <[email protected]>; +Cc: [email protected] On Thu, Feb 5, 2026 at 3:47 PM Shinya Kato <[email protected]> wrote: > > On Fri, Jan 23, 2026 at 7:22 PM Fujii Masao <[email protected]> wrote: > > > > Hi, > > > > synchronized_standby_slots is defined in guc_parameter.dat as part of > > the REPLICATION_PRIMARY group and appears under the "Primary Server" > > section in postgresql.conf.sample. However, in the documentation > > its description is placed under the "Sending Servers" section. > > > > Given this, it seems the description should also be under "Primary Server" > > in the documentation. I've attached a patch that moves it there. > > Thank you for the patch! The patch LGTM. Thanks for the review! I've pushed the patch. > > Alternatively, if synchronized_standby_slots is intended to be set also > > on a standby in cascading replication setups, then the current documentation > > placement may be correct, and instead guc_parameter.dat and > > postgresql.conf.sample should be updated. My understanding, though, > > is that this parameter is normally set only on the primary. Right? > > You're right. PhysicalWakeupLogicalWalSnd() in walsender.c has this check: > > /* > * If we are running in a standby, there is no need to wake up walsenders. > * This is because we do not support syncing slots to cascading standbys, > * so, there are no walsenders waiting for standbys to catch up. > */ > if (RecoveryInProgress()) > return; > > So this parameter is only meaningful on the primary. Thanks for confirming this! Regards, -- Fujii Masao ^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~2026-02-06 00:43 UTC | newest] Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2026-01-23 10:21 Placement of synchronized_standby_slots description in config.sgml Fujii Masao <[email protected]> 2026-02-05 06:47 ` Shinya Kato <[email protected]> 2026-02-06 00:43 ` Fujii Masao <[email protected]>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox