standby, as described
    in <xref linkend="continuous-archiving"/>. The archive location should be
    accessible from the standby even when the primary is down, i.e., it should
    reside on the standby server itself or another trusted server, not on
    the primary server.
   </para>

   <para>
    If you want to use streaming replication, set up authentication on the
    primary server to allow replication connections from the standby
    server(s); that is, create a role and provide a suitable entry or
    entries in <filename>pg_hba.conf</filename> with the database field set to
    <literal>replication</literal>.  Also ensure <varname>max_wal_senders</varname> is set
    to a sufficiently large value in the configuration file of the primary
    server. If replication slots will be used,
    ensure that <varname>max_replication_slots</varname> is set sufficiently
    high as well.
   </para>

   <para>
    Take a base backup as described in <xref linkend="backup-base-backup"/>
    to bootstrap the standby server.
   </para>
  </sect2>

  <sect2 id="standby-server-setup">
   <title>Setting Up a Standby Server</title>

   <para>
    To set up the standby server, restore the base backup taken from primary
    server (see <xref linkend="backup-pitr-recovery"/>). Create a file
    <link linkend="file-standby-signal"><filename>standby.signal</filename></link><indexterm><primary>standby.signal</primary></indexterm>
    in the standby's cluster data
    directory. Set <xref linkend="guc-restore-command"/> to a simple command to copy files from
    the WAL archive. If you plan to have multiple standby servers for high
    availability purposes, make sure that <varname>recovery_target_timeline</varname> is set to
    <literal>latest</literal> (the default), to make the standby server follow the timeline change
    that occurs at failover to another standby.
   </para>

   <note>
     <para>
     <xref linkend="guc-restore-command"/> should return immediately
     if the file does not exist; the server will retry the command again if
     necessary.
    </para>
   </note>

   <para>
     If you want to use streaming replication, fill in
     <xref linkend="guc-primary-conninfo"/> with a libpq connection string, including
     the host name (or IP address) and any additional details needed to
     connect to the primary server. If the primary needs a password for
     authentication, the password needs to be specified in
     <xref linkend="guc-primary-conninfo"/> as well.
   </para>

   <para>
    If you're setting up the standby server for high availability purposes,
    set up WAL archiving, connections and authentication like the primary
    server, because the standby server will work as a primary server after
    failover.
   </para>

   <para>
    If you're using a WAL archive, its size can be minimized using the <xref
    linkend="guc-archive-cleanup-command"/> parameter to remove files that are no
    longer required by the standby server.
    The <application>pg_archivecleanup</application> utility is designed specifically to
    be used with <varname>archive_cleanup_command</varname> in typical single-standby
    configurations, see <xref linkend="pgarchivecleanup"/>.
    Note however, that if you're using the archive for backup purposes, you
    need to retain files needed to recover from at least the latest base
    backup, even if they're no longer needed by the standby.
   </para>

   <para>
    A simple example of configuration is:
<programlisting>
primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass options=''-c wal_sender_timeout=5000'''
restore_command = 'cp /path/to/archive/%f %p'
archive_cleanup_command = 'pg_archivecleanup /path/to/archive %r'
</programlisting>
   </para>

   <para>
    You can have any number of standby servers, but if you use streaming
    replication, make sure you set <varname>max_wal_senders</varname> high enough in
    the primary to allow them to be connected simultaneously.