<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.
   </para>

  </sect2>

  <sect2 id="streaming-replication">
   <title>Streaming Replication</title>

   <indexterm zone="high-availability">
    <primary>Streaming Replication</primary>
   </indexterm>

   <para>
    Streaming replication allows a standby server to stay more up-to-date
    than is possible with file-based log shipping. The standby connects
    to the primary, which streams WAL records to the standby as they're
    generated, without waiting for the WAL file to be filled.
   </para>

   <para>
    Streaming replication is asynchronous by default
    (see <xref linkend="synchronous-replication"/>), in which case there is
    a small delay between committing a transaction in the primary and the
    changes becoming visible in the standby. This delay is however much
    smaller than with file-based log shipping, typically under one second
    assuming the standby is powerful enough to keep up with the load. With
    streaming replication, <varname>archive_timeout</varname> is not required to
    reduce the data loss window.
   </para>

   <para>
    If you use streaming replication without file-based continuous
    archiving, the server might recycle old WAL segments before the standby
    has received them.  If this occurs, the standby will need to be
    reinitialized from a new base backup.  You can avoid this by setting
    <varname>wal_keep_size</varname> to a value large enough to ensure that
    WAL segments are not recycled too early, or by configuring a replication
    slot for the standby.  If you set up a WAL archive that's accessible from
    the standby, these solutions are not required, since the standby can
    always use the archive to catch up provided it retains enough segments.
   </para>

   <para>
    To use streaming replication, set up a file-based log-shipping standby
    server as described in <xref linkend="warm-standby"/>. The step that
    turns a file-based log-shipping standby into streaming replication
    standby is setting the <varname>primary_conninfo</varname> setting
    to point to the primary server. Set
    <xref linkend="guc-listen-addresses"/> and authentication options
    (see <filename>pg_hba.conf</filename>) on the primary so that the standby server
    can connect to the <literal>replication</literal> pseudo-database on the primary
    server (see <xref linkend="streaming-replication-authentication"/>).
   </para>

   <para>
    On systems that support the keepalive socket option, setting
    <xref linkend="guc-tcp-keepalives-idle"/>,
    <xref linkend="guc-tcp-keepalives-interval"/> and
    <xref linkend="guc-tcp-keepalives-count"/> helps the primary promptly
    notice a broken connection.
   </para>

   <para>
    Set the maximum number of concurrent connections from the standby servers
    (see <xref linkend="guc-max-wal-senders"/> for details).
   </para>

   <para>
    When the standby is started and <varname>primary_conninfo</varname> is set
    correctly, the standby will connect