to idle timeout occurs during checkpoint.
        Because checkpoints happen at <varname>checkpoint_timeout</varname>
        intervals, there can be some lag between when the
        <varname>idle_replication_slot_timeout</varname> was exceeded and when
        the slot invalidation is triggered at the next checkpoint.
        To avoid such lags, users can force a checkpoint to promptly invalidate
        inactive slots. The duration of slot inactivity is calculated using the
        slot's <link linkend="view-pg-replication-slots">pg_replication_slots</link>.<structfield>inactive_since</structfield>
        value.
       </para>

       <para>
        Note that the idle timeout invalidation mechanism is not applicable
        for slots that do not reserve WAL or for slots on the standby server
        that are being synced from the primary server (i.e., standby slots
        having <link linkend="view-pg-replication-slots">pg_replication_slots</link>.<structfield>synced</structfield>
        value <literal>true</literal>). Synced slots are always considered to
        be inactive because they don't perform logical decoding to produce
        changes.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-wal-sender-timeout" xreflabel="wal_sender_timeout">
      <term><varname>wal_sender_timeout</varname> (<type>integer</type>)
      <indexterm>
       <primary><varname>wal_sender_timeout</varname> configuration parameter</primary>
      </indexterm>
      </term>
      <listitem>
       <para>
        Terminate replication connections that are inactive for longer
        than this amount of time. This is useful for
        the sending server to detect a standby crash or network outage.
        If this value is specified without units, it is taken as milliseconds.
        The default value is 60 seconds.
        A value of zero disables the timeout mechanism.
       </para>
       <para>
        With a cluster distributed across multiple geographic
        locations, using different values per location brings more flexibility
        in the cluster management. A smaller value is useful for faster
        failure detection with a standby having a low-latency network
        connection, and a larger value helps in judging better the health
        of a standby if located on a remote location, with a high-latency
        network connection.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-track-commit-timestamp" xreflabel="track_commit_timestamp">
      <term><varname>track_commit_timestamp</varname> (<type>boolean</type>)
      <indexterm>
       <primary><varname>track_commit_timestamp</varname> configuration parameter</primary>
      </indexterm>
      </term>
      <listitem>
       <para>
        Record commit time of transactions. This parameter
        can only be set in <filename>postgresql.conf</filename> file or on the server
        command line. The default value is <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,