identity <literal>FULL</literal> is
    specified, indexes can be used on the subscriber side for searching the
    rows.  Candidate indexes must be btree or hash, non-partial, and the
    leftmost index field must be a column (not an expression) that references
    the published table column.  These restrictions on the non-unique index
    properties adhere to some of the restrictions that are enforced for
    primary keys.  If there are no such suitable indexes, the search on the
    subscriber side can be very inefficient, therefore replica identity
    <literal>FULL</literal> should only be used as a fallback if no other
    solution is possible.
   </para>

   <para>
    If a replica identity other than <literal>FULL</literal> is set on the
    publisher side, a replica identity comprising the same or fewer columns
    must also be set on the subscriber side.
   </para>

   <para>
    Tables with a replica identity defined as <literal>NOTHING</literal>,
    <literal>DEFAULT</literal> without a primary key, or <literal>USING
    INDEX</literal> with a dropped index, cannot support
    <command>UPDATE</command> or <command>DELETE</command> operations when
    included in a publication replicating these actions. Attempting such
    operations will result in an error on the publisher.
   </para>

   <para>
    <command>INSERT</command> operations can proceed regardless of any replica identity.
   </para>

   <para>
    See <link linkend="sql-altertable-replica-identity"><literal>ALTER TABLE...REPLICA IDENTITY</literal></link>
    for details on how to set the replica identity.
   </para>
  </sect2>

 </sect1>

 <sect1 id="logical-replication-subscription">
  <title>Subscription</title>

  <para>
   A <firstterm>subscription</firstterm> is the downstream side of logical
   replication.  The node where a subscription is defined is referred to as
   the <firstterm>subscriber</firstterm>.  A subscription defines the connection
   to another database and set of publications (one or more) to which it wants
   to subscribe.
  </para>

  <para>
   The subscriber database behaves in the same way as any other PostgreSQL
   instance and can be used as a publisher for other databases by defining its
   own publications.
  </para>

  <para>
   A subscriber node may have multiple subscriptions if desired.  It is
   possible to define multiple subscriptions between a single
   publisher-subscriber pair, in which case care must be taken to ensure
   that the subscribed publication objects don't overlap.
  </para>

  <para>
   Each subscription will receive changes via one replication slot (see
   <xref linkend="streaming-replication-slots"/>).  Additional replication
   slots may be required for the initial data synchronization of
   pre-existing table data and those will be dropped at the end of data
   synchronization.
  </para>

  <para>
   A logical replication subscription can be a standby for synchronous
   replication (see <xref linkend="synchronous-replication"/>).  The standby
   name is by default the subscription name.  An alternative name can be
   specified as <literal>application_name</literal> in the connection
   information of the subscription.
  </para>

  <para>
   Subscriptions are dumped by <command>pg_dump</command> if the current user
   is a superuser.  Otherwise a warning is written and subscriptions are
   skipped, because non-superusers cannot read all subscription information
   from the <structname>pg_subscription</structname> catalog.
  </para>

  <para>
   The subscription is added using <link linkend="sql-createsubscription"><command>CREATE SUBSCRIPTION</command></link> and
   can be stopped/resumed at any time using the
   <link linkend="sql-altersubscription"><command>ALTER SUBSCRIPTION</command></link> command and removed using
   <link linkend="sql-dropsubscription"><command>DROP SUBSCRIPTION</command></link>.
  </para>

  <para>
   When a subscription is dropped and recreated, the synchronization
   information