Home • Explore • Blog • CI
☰



postgresql
71th chunk of `doc/src/sgml/config.sgml`
9b032c03b89c8aca40279ee4d7074b39f8b9edc928bee4880000000100000fa0
 <literal>off</literal>.
       </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>
    </sect2>

    <sect2 id="runtime-config-replication-primary">
     <title>Primary Server</title>

     <para>
      These parameters can be set on the primary server that is
      to send replication data to one or more standby servers.
      Note that in addition to these parameters,
      <xref linkend="guc-wal-level"/> must be set appropriately on the primary
      server, and optionally WAL archiving can be enabled as
      well (see <xref linkend="runtime-config-wal-archiving"/>).
      The values of these parameters on standby servers are irrelevant,
      although you may wish to set them there in preparation for the
      possibility of a standby becoming the primary.
     </para>

    <variablelist>

     <varlistentry id="guc-synchronous-standby-names" xreflabel="synchronous_standby_names">
      <term><varname>synchronous_standby_names</varname> (<type>string</type>)
      <indexterm>
       <primary><varname>synchronous_standby_names</varname> configuration parameter</primary>
      </indexterm>
      </term>
      <listitem>
       <para>
        Specifies a list of standby servers that can support
        <firstterm>synchronous replication</firstterm>, as described in
        <xref linkend="synchronous-replication"/>.
        There will be one or more active synchronous standbys;
        transactions waiting for commit will be allowed to proceed after
        these standby servers confirm receipt of their data.
        The synchronous standbys will be those whose names appear
        in this list, and
        that are both currently connected and streaming data in real-time
        (as shown by a state of <literal>streaming</literal> in the
        <link linkend="monitoring-pg-stat-replication-view">
Title: Synchronized Standby Slots Configuration and Primary Server Settings
Summary
This section elaborates on `synchronized_standby_slots`, ensuring logical replication failover slots only consume changes after physical standbys receive and flush WAL. It specifies that the physical standby be listed when switching to physical after promotion, and replication halts if slots are invalid. Certain functions block until all physical slots confirm WAL receipt. Standbys need `sync_replication_slots = true`. It moves to Primary Server settings, noting `wal_level` and optional WAL archiving. These values on standbys are irrelevant unless preparing for promotion. Finally, it introduces `synchronous_standby_names` for synchronous replication support.