standby
        server can recover by fetching the segment from archive, if WAL
        archiving is in use.)
       </para>

       <para>
        This sets only the minimum size of segments retained in
        <filename>pg_wal</filename>; the system might need to retain more segments
        for WAL archival or to recover from a checkpoint. If
        <varname>wal_keep_size</varname> is zero (the default), the system
        doesn't keep any extra segments for standby purposes, so the number
        of old WAL segments available to standby servers is a function of
        the location of the previous checkpoint and status of WAL
        archiving.
        If this value is specified without units, it is taken as megabytes.
        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-max-slot-wal-keep-size" xreflabel="max_slot_wal_keep_size">
       <term><varname>max_slot_wal_keep_size</varname> (<type>integer</type>)
       <indexterm>
        <primary><varname>max_slot_wal_keep_size</varname> configuration parameter</primary>
       </indexterm>
       </term>
       <listitem>
       <para>
        Specify the maximum size of WAL files
        that <link linkend="streaming-replication-slots">replication
        slots</link> are allowed to retain in the <filename>pg_wal</filename>
        directory at checkpoint time.
        If <varname>max_slot_wal_keep_size</varname> is -1 (the default),
        replication slots may retain an unlimited amount of WAL files.  Otherwise, if
        restart_lsn of a replication slot falls behind the current LSN by more
        than the given size, the standby using the slot may no longer be able
        to continue replication due to removal of required WAL files. You
        can see the WAL availability of replication slots
        in <link linkend="view-pg-replication-slots">pg_replication_slots</link>.
        If this value is specified without units, it is taken as megabytes.
        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-idle-replication-slot-timeout" xreflabel="idle_replication_slot_timeout">
      <term><varname>idle_replication_slot_timeout</varname> (<type>integer</type>)
      <indexterm>
       <primary><varname>idle_replication_slot_timeout</varname> configuration parameter</primary>
      </indexterm>
      </term>
      <listitem>
       <para>
        Invalidate replication slots that have remained idle longer than this
        duration. If this value is specified without units, it is taken as
        minutes. A value of zero (the default) disables the idle timeout
        invalidation mechanism. This parameter can only be set in the
        <filename>postgresql.conf</filename> file or on the server command
        line.
       </para>

       <para>
        Slot invalidation due 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>