postgres.git / summary / log / commit / refs
commit e35add48ccc2e5aa94de360f1a43c6c150bda54a
Author: Fujii Masao <fujii@postgresql.org>
Date: Fri Feb 06 00:40:05 2026 +0000
First released in: 17.8, 18.2
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.
Since synchronized_standby_slots only takes effect on the primary server,
this commit moves its documentation to the "Primary Server" section to
match its behavior and other references.
Backpatch to v17 where synchronized_standby_slots was added.
Author: Fujii Masao <masao.fujii@gmail.com>
Reviewed-by: Shinya Kato <shinya11.kato@gmail.com>
Discussion: https://postgr.es/m/CAHGQGwE_LwgXgCrqd08OFteJqdERiF3noqOKu2vt7Kjk4vMiGg@mail.gmail.com
Backpatch-through: 17
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>
[parent: 9476ef206c64]