Therefore, it is unwise to use a very short
        <varname>archive_timeout</varname> &mdash; it will bloat your archive
        storage.  <varname>archive_timeout</varname> settings of a minute or so are
        usually reasonable.  You should consider using streaming replication,
        instead of archiving, if you want data to be copied off the primary
        server more quickly than that.
        If this value is specified without units, it is taken as seconds.
        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-wal-recovery">

    <title>Recovery</title>

     <indexterm>
      <primary>configuration</primary>
      <secondary>of recovery</secondary>
      <tertiary>general settings</tertiary>
     </indexterm>

    <para>
     This section describes the settings that apply to recovery in general,
     affecting crash recovery, streaming replication and archive-based
     replication.
    </para>


    <variablelist>
     <varlistentry id="guc-recovery-prefetch" xreflabel="recovery_prefetch">
      <term><varname>recovery_prefetch</varname> (<type>enum</type>)
      <indexterm>
       <primary><varname>recovery_prefetch</varname> configuration parameter</primary>
      </indexterm>
      </term>
      <listitem>
       <para>
        Whether to try to prefetch blocks that are referenced in the WAL that
        are not yet in the buffer pool, during recovery.  Valid values are
        <literal>off</literal>, <literal>on</literal> and
        <literal>try</literal> (the default).  The setting
        <literal>try</literal> enables
        prefetching only if the operating system provides support for issuing
        read-ahead advice.
       </para>
       <para>
        Prefetching blocks that will soon be needed can reduce I/O wait times
        during recovery with some workloads.
        See also the <xref linkend="guc-wal-decode-buffer-size"/> and
        <xref linkend="guc-maintenance-io-concurrency"/> settings, which limit
        prefetching activity.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-wal-decode-buffer-size" xreflabel="wal_decode_buffer_size">
      <term><varname>wal_decode_buffer_size</varname> (<type>integer</type>)
      <indexterm>
       <primary><varname>wal_decode_buffer_size</varname> configuration parameter</primary>
      </indexterm>
      </term>
      <listitem>
       <para>
        A limit on how far ahead the server can look in the WAL, to find
        blocks to prefetch.  If this value is specified without units, it is
        taken as bytes.
        The default is 512kB.
       </para>
      </listitem>
     </varlistentry>

    </variablelist>
   </sect2>

  <sect2 id="runtime-config-wal-archive-recovery">

    <title>Archive Recovery</title>

    <indexterm>
     <primary>configuration</primary>
     <secondary>of recovery</secondary>
     <tertiary>of a standby server</tertiary>
    </indexterm>

    <para>
     This section describes the settings that apply only for the duration of
     the recovery.  They must be reset for any subsequent recovery you wish to
     perform.
    </para>

    <para>
     <quote>Recovery</quote> covers using the server as a standby or for
     executing a targeted recovery.  Typically, standby mode would be used to
     provide high availability and/or read scalability, whereas a targeted
     recovery is used to recover from data loss.
    </para>

    <para>
     To start the server in standby mode, create a file called
     <filename>standby.signal</filename><indexterm><primary>standby.signal</primary></indexterm>
     in the data directory.  The server will enter recovery and will not stop
     recovery when the end of archived WAL is reached, but will keep trying to
     continue recovery by connecting to the sending server