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>
    Similarly, <xref linkend="guc-hot-standby-feedback"/> on its own, without
    also using a replication slot, provides protection against relevant rows
    being removed by vacuum, but provides no protection during any time period
    when the standby is not connected.
   </para>

   <caution>
    <para>
     Beware that replication slots can cause the server to retain so
     many WAL segments that they fill up the space allocated for
     <literal>pg_wal</literal>.
     <xref linkend="guc-max-slot-wal-keep-size"/> can be used to limit the size
     of WAL files retained by replication slots.
    </para>
   </caution>

   <sect3 id="streaming-replication-slots-manipulation">
    <title>Querying and Manipulating Replication Slots</title>
    <para>
     Each replication slot has a name, which can contain lower-case letters,
     numbers, and the underscore character.
    </para>
    <para>
     Existing replication slots and their state can be seen in the
     <link linkend="view-pg-replication-slots"><structname>pg_replication_slots</structname></link>
     view.
    </para>
    <para>
     Slots can be created and dropped either via the streaming replication
     protocol (see <xref linkend="protocol-replication"/>) or via SQL
     functions (see <xref linkend="functions-replication"/>).
    </para>
   </sect3>
   <sect3 id="streaming-replication-slots-config">
    <title>Configuration Example</title>
    <para>
     You can create a replication slot like this:
<programlisting>
postgres=# SELECT * FROM pg_create_physical_replication_slot('node_a_slot');
  slot_name  | lsn
-------------+-----
 node_a_slot |

postgres=# SELECT slot_name, slot_type, active FROM pg_replication_slots;
  slot_name  | slot_type | active
-------------+-----------+--------
 node_a_slot | physical  | f
(1 row)
</programlisting>
     To configure the standby to use this slot, <varname>primary_slot_name</varname>
     should be configured on the standby. Here is a simple example:
<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