transaction commits.
        Other records are replayed as quickly as possible, which
        is not a problem because MVCC visibility rules ensure their effects
        are not visible until the corresponding commit record is applied.
       </para>
       <para>
        The delay occurs once the database in recovery has reached a consistent
        state, until the standby is promoted or triggered. After that the standby
        will end recovery without further waiting.
       </para>
       <para>
        WAL records must be kept on the standby until they are ready to be
        applied. Therefore, longer delays will result in a greater accumulation
        of WAL files, increasing disk space requirements for the standby's
        <filename>pg_wal</filename> directory.
       </para>
       <para>
        This parameter is intended for use with streaming replication deployments;
        however, if the parameter is specified it will be honored in all cases
        except crash recovery.

        <varname>hot_standby_feedback</varname> will be delayed by use of this feature
        which could lead to bloat on the primary; use both together with care.

        <warning>
         <para>
          Synchronous replication is affected by this setting when <varname>synchronous_commit</varname>
          is set to <literal>remote_apply</literal>; every <literal>COMMIT</literal>
          will need to wait to be applied.
         </para>
        </warning>
       </para>
       <para>
        This parameter can only be set in the <filename>postgresql.conf</filename>
        file or on the server command line.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-sync-replication-slots" xreflabel="sync_replication_slots">
      <term><varname>sync_replication_slots</varname> (<type>boolean</type>)
      <indexterm>
       <primary><varname>sync_replication_slots</varname> configuration parameter</primary>
      </indexterm>
      </term>
      <listitem>
       <para>
        It enables a physical standby to synchronize logical failover slots
        from the primary server so that logical subscribers can resume
        replication from the new primary server after failover.
       </para>
       <para>
        It is disabled by default. This parameter can only be set in the
        <filename>postgresql.conf</filename> file or on the server command line.
       </para>
      </listitem>
     </varlistentry>
     </variablelist>
    </sect2>

    <sect2 id="runtime-config-replication-subscriber">
     <title>Subscribers</title>

     <para>
      These settings control the behavior of a logical replication subscriber.
      Their values on the publisher are irrelevant.
      See <xref linkend="logical-replication-config"/> for more details.
     </para>

     <variablelist>

     <varlistentry id="guc-max-active-replication-origins" xreflabel="max_active_replication_origins">
      <term><varname>max_active_replication_origins</varname> (<type>integer</type>)
       <indexterm>
        <primary><varname>max_active_replication_origins</varname> configuration parameter</primary>
       </indexterm>
      </term>
      <listitem>
       <para>
        Specifies how many replication origins (see
        <xref linkend="replication-origins"/>) can be tracked simultaneously,
        effectively limiting how many logical replication subscriptions can
        be created on the server. Setting it to a lower value than the current
        number of tracked replication origins (reflected in
        <link linkend="view-pg-replication-origin-status">pg_replication_origin_status</link>)
        will prevent the server from starting. It defaults to 10. This parameter
        can only be set at server start.

        <literal>max_active_replication_origins</literal> must be set to at least the
        number of subscriptions that will be added to the subscriber, plus some
        reserve for table synchronization.