server continues to accumulate WAL segment files in
        the expectation that a command will soon be provided.  Setting
        <varname>archive_command</varname> to a command that does nothing but
        return true, e.g., <literal>/bin/true</literal> (<literal>REM</literal> on
        Windows), effectively disables
        archiving, but also breaks the chain of WAL files needed for
        archive recovery, so it should only be used in unusual circumstances.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-archive-library" xreflabel="archive_library">
      <term><varname>archive_library</varname> (<type>string</type>)
      <indexterm>
       <primary><varname>archive_library</varname> configuration parameter</primary>
      </indexterm>
      </term>
      <listitem>
       <para>
        The library to use for archiving completed WAL file segments.  If set to
        an empty string (the default), archiving via shell is enabled, and
        <xref linkend="guc-archive-command"/> is used.  If both
        <varname>archive_command</varname> and <varname>archive_library</varname>
        are set, an error will be raised.  Otherwise, the specified
        shared library is used for archiving. The WAL archiver process is
        restarted by the postmaster when this parameter changes. For more
        information, see <xref linkend="backup-archiving-wal"/> and
        <xref linkend="archive-modules"/>.
       </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-archive-timeout" xreflabel="archive_timeout">
      <term><varname>archive_timeout</varname> (<type>integer</type>)
      <indexterm>
       <primary><varname>archive_timeout</varname> configuration parameter</primary>
      </indexterm>
      </term>
      <listitem>
       <para>
        The <xref linkend="guc-archive-command"/> or <xref linkend="guc-archive-library"/> is only invoked for
        completed WAL segments. Hence, if your server generates little WAL
        traffic (or has slack periods where it does so), there could be a
        long delay between the completion of a transaction and its safe
        recording in archive storage.  To limit how old unarchived
        data can be, you can set <varname>archive_timeout</varname> to force the
        server to switch to a new WAL segment file periodically.  When this
        parameter is greater than zero, the server will switch to a new
        segment file whenever this amount of time has elapsed since the last
        segment file switch, and there has been any database activity,
        including a single checkpoint (checkpoints are skipped if there is
        no database activity).  Note that archived files that are closed
        early due to a forced switch are still the same length as completely
        full files.  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