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 to the primary after replaying all
    WAL files available in the archive. If the connection is established
    successfully, you will see a <literal>walreceiver</literal> in the standby, and
    a corresponding <literal>walsender</literal> process in the primary.
   </para>

   <sect3 id="streaming-replication-authentication">
    <title>Authentication</title>
    <para>
     It is very important that the access privileges for replication be set up
     so that only trusted users can read the WAL stream, because it is
     easy to extract privileged information from it.  Standby servers must
     authenticate to the primary as an account that has the
     <literal>REPLICATION</literal> privilege or a superuser. It is
     recommended to create a dedicated user account with
     <literal>REPLICATION</literal> and <literal>LOGIN</literal>
     privileges for replication. While <literal>REPLICATION</literal>
     privilege gives very high permissions, it does not allow the user to
     modify any data on the primary system, which the
     <literal>SUPERUSER</literal> privilege does.
    </para>

    <para>
     Client authentication for replication is controlled by a
     <filename>pg_hba.conf</filename> record specifying <literal>replication</literal> in the
     <replaceable>database</replaceable> field. For example, if the standby is running on
     host IP <literal>192.168.1.100</literal> and the account name for replication
     is <literal>foo</literal>, the administrator can add the following line to the
     <filename>pg_hba.conf</filename> file on the primary:

<programlisting>
# Allow the user "foo" from host 192.168.1.100 to connect to the primary
# as a replication standby if the user's password is correctly supplied.
#
# TYPE  DATABASE        USER            ADDRESS                 METHOD
host    replication     foo             192.168.1.100/32        md5
</programlisting>
    </para>
    <para>
     The host name and port number of the primary, connection user name,
     and password are specified in the <xref linkend="guc-primary-conninfo"/>.
     The password can also be set in the <filename>~/.pgpass</filename> file on the
     standby (specify <literal>replication</literal> in the <replaceable>database</replaceable>
     field).
     For example, if the primary is running on host IP <literal>192.168.1.50</literal>,
     port <literal>5432</literal>, the account name for replication is
     <literal>foo</literal>, and the password is <literal>foopass</literal>, the administrator
     can add the following line to the <filename>postgresql.conf</filename> file on the
     standby:

<programlisting>
# The standby connects to the primary that is running on host 192.168.1.50
# and port 5432 as the user "foo" whose password is "foopass".
primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass'
</programlisting>
    </para>
   </sect3>

   <sect3 id="streaming-replication-monitoring">
    <title>Monitoring</title>