units, it is taken as milliseconds.
        The default value is 5 seconds.
        This parameter can only be set in
        the <filename>postgresql.conf</filename> file or on the server
        command line.
       </para>
       <para>
        This parameter is useful in configurations where a node in recovery
        needs to control the amount of time to wait for new WAL data to be
        available. For example, in archive recovery, it is possible to
        make the recovery more responsive in the detection of a new WAL
        file by reducing the value of this parameter. On a system with
        low WAL activity, increasing it reduces the amount of requests necessary
        to access WAL archives, something useful for example in cloud
        environments where the number of times an infrastructure is accessed
        is taken into account.
       </para>
       <para>
        In logical replication, this parameter also limits how often a failing
        replication apply worker or table synchronization worker will be
        respawned.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-recovery-min-apply-delay" xreflabel="recovery_min_apply_delay">
      <term><varname>recovery_min_apply_delay</varname> (<type>integer</type>)
      <indexterm>
        <primary><varname>recovery_min_apply_delay</varname> configuration parameter</primary>
      </indexterm>
      </term>
      <listitem>
       <para>
        By default, a standby server restores WAL records from the
        sending server as soon as possible. It may be useful to have a time-delayed
        copy of the data, offering opportunities to correct data loss errors.
        This parameter allows you to delay recovery by a specified amount
        of time.  For example, if
        you set this parameter to <literal>5min</literal>, the standby will
        replay each transaction commit only when the system time on the standby
        is at least five minutes past the commit time reported by the primary.
        If this value is specified without units, it is taken as milliseconds.
        The default is zero, adding no delay.
       </para>
       <para>
        It is possible that the replication delay between servers exceeds the
        value of this parameter, in which case no delay is added.
        Note that the delay is calculated between the WAL time stamp as written
        on primary and the current time on the standby. Delays in transfer
        because of network lag or cascading replication configurations
        may reduce the actual wait time significantly. If the system
        clocks on primary and standby are not synchronized, this may lead to
        recovery applying records earlier than expected; but that is not a
        major issue because useful settings of this parameter are much larger
        than typical time deviations between servers.
       </para>
       <para>
        The delay occurs only on WAL records for 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.