<programlisting>
primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass'
primary_slot_name = 'node_a_slot'
</programlisting>
    </para>
   </sect3>
  </sect2>

  <sect2 id="cascading-replication">
   <title>Cascading Replication</title>

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

   <para>
    The cascading replication feature allows a standby server to accept replication
    connections and stream WAL records to other standbys, acting as a relay.
    This can be used to reduce the number of direct connections to the primary
    and also to minimize inter-site bandwidth overheads.
   </para>

   <para>
    A standby acting as both a receiver and a sender is known as a cascading
    standby.  Standbys that are more directly connected to the primary are known
    as upstream servers, while those standby servers further away are downstream
    servers.  Cascading replication does not place limits on the number or
    arrangement of downstream servers, though each standby connects to only
    one upstream server which eventually links to a single primary server.
   </para>

   <para>
    A cascading standby sends not only WAL records received from the
    primary but also those restored from the archive. So even if the replication
    connection in some upstream connection is terminated, streaming replication
    continues downstream for as long as new WAL records are available.
   </para>

   <para>
    Cascading replication is currently asynchronous. Synchronous replication
    (see <xref linkend="synchronous-replication"/>) settings have no effect on
    cascading replication at present.
   </para>

   <para>
    Hot standby feedback propagates upstream, whatever the cascaded arrangement.
   </para>

   <para>
    If an upstream standby server is promoted to become the new primary, downstream
    servers will continue to stream from the new primary if
    <varname>recovery_target_timeline</varname> is set to <literal>'latest'</literal> (the default).
   </para>

   <para>
    To use cascading replication, set up the cascading standby so that it can
    accept replication connections (that is, set
    <xref linkend="guc-max-wal-senders"/> and <xref linkend="guc-hot-standby"/>,
    and configure
    <link linkend="auth-pg-hba-conf">host-based authentication</link>).
    You will also need to set <varname>primary_conninfo</varname> in the downstream
    standby to point to the cascading standby.
   </para>
  </sect2>

  <sect2 id="synchronous-replication">
   <title>Synchronous Replication</title>

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

   <para>
    <productname>PostgreSQL</productname> streaming replication is asynchronous by
    default. If the primary server
    crashes then some transactions that were committed may not have been
    replicated to the standby server, causing data loss. The amount
    of data loss is proportional to the replication delay at the time of
    failover.
   </para>

   <para>
    Synchronous replication offers the ability to confirm that all changes
    made by a transaction have been transferred to one or more synchronous
    standby servers. This extends that standard level of durability
    offered by a transaction commit. This level of protection is referred
    to as 2-safe replication in computer science theory, and group-1-safe
    (group-safe and 1-safe) when <varname>synchronous_commit</varname> is set to
    <literal>remote_write</literal>.
   </para>

   <para>
    When requesting synchronous replication, each commit of a
    write transaction will wait until confirmation is
    received that the commit has been written to the write-ahead log on disk
    of both the primary and standby server. The only possibility that data
    can be lost is if both the primary and the standby suffer crashes at the
    same time. This can provide a much higher level