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>
    <para>
     An important health indicator of streaming replication is the amount
     of WAL records generated in the primary, but not yet applied in the
     standby. You can calculate this lag by comparing the current WAL write
     location on the primary with the last WAL location received by the
     standby. These locations can be retrieved using
     <function>pg_current_wal_lsn</function> on the primary and
     <function>pg_last_wal_receive_lsn</function> on the standby,
     respectively (see <xref linkend="functions-admin-backup-table"/> and
     <xref linkend="functions-recovery-info-table"/> for details).
     The last WAL receive location in the standby is also displayed in the
     process status of the WAL receiver process, displayed using the
     <command>ps</command> command (see <xref linkend="monitoring-ps"/> for details).
    </para>
    <para>
     You can retrieve a list of WAL sender processes via the
     <link linkend="monitoring-pg-stat-replication-view"><structname>
     pg_stat_replication</structname></link> view. Large differences between
     <function>pg_current_wal_lsn</function> and the view's <literal>sent_lsn</literal> field
     might indicate that the primary server is under heavy load, while
     differences between <literal>sent_lsn</literal> and
     <function>pg_last_wal_receive_lsn</function> on the standby might indicate
     network delay, or that the standby is under heavy load.
    </para>
    <para>
     On a hot standby, the status of the WAL receiver process can be retrieved
     via the <link linkend="monitoring-pg-stat-wal-receiver-view">
     <structname>pg_stat_wal_receiver</structname></link> view.  A large
     difference between <function>pg_last_wal_replay_lsn</function> and the
     view's <literal>flushed_lsn</literal> indicates that WAL is being
     received faster than it can be replayed.
    </para>
   </sect3>
  </sect2>

  <sect2 id="streaming-replication-slots">
   <title>Replication Slots</title>
   <indexterm>
    <primary>replication slot</primary>
    <secondary>streaming replication</secondary>
   </indexterm>
   <para>
    Replication slots provide an automated way to ensure that the
    primary server does
    not remove WAL segments until they have been received by all standbys,
    and that the primary does not remove rows which could cause a
    <link linkend="hot-standby-conflict">recovery conflict</link> even when the
    standby is disconnected.
   </para>
   <para>
    In lieu of using replication slots, it is possible to prevent the removal
    of old WAL segments using <xref linkend="guc-wal-keep-size"/>, or by
    storing the segments in an archive using
    <xref linkend="guc-archive-command"/> or <xref linkend="guc-archive-library"/>.
    A disadvantage of these methods is that they
    often result in retaining more WAL segments than
    required, whereas replication slots retain only the number of segments
    known to be needed.
   </para>
   <para>