hand, if there are other writes done either by an application or by other
  subscribers to the same set of tables, conflicts can arise.
 </para>

 <sect1 id="logical-replication-publication">
  <title>Publication</title>

  <para>
   A <firstterm>publication</firstterm> can be defined on any physical
   replication primary.  The node where a publication is defined is referred to
   as <firstterm>publisher</firstterm>.  A publication is a set of changes
   generated from a table or a group of tables, and might also be described as
   a change set or replication set.  Each publication exists in only one database.
  </para>

  <para>
   Publications are different from schemas and do not affect how the table is
   accessed.  Each table can be added to multiple publications if needed.
   Publications may currently only contain tables and all tables in schema.
   Objects must be added explicitly, except when a publication is created for
   <literal>ALL TABLES</literal>.
  </para>

  <para>
   Publications can choose to limit the changes they produce to
   any combination of <command>INSERT</command>, <command>UPDATE</command>,
   <command>DELETE</command>, and <command>TRUNCATE</command>, similar to how triggers are fired by
   particular event types. By default, all operation types are replicated.
   These publication specifications apply only for DML operations; they do not affect the initial
   data synchronization copy. (Row filters have no effect for
   <command>TRUNCATE</command>. See <xref linkend="logical-replication-row-filter"/>).
  </para>

  <para>
   Every publication can have multiple subscribers.
  </para>

  <para>
   A publication is created using the <link linkend="sql-createpublication"><command>CREATE PUBLICATION</command></link>
   command and may later be altered or dropped using corresponding commands.
  </para>

  <para>
   The individual tables can be added and removed dynamically using
   <link linkend="sql-alterpublication"><command>ALTER PUBLICATION</command></link>.  Both the <literal>ADD
   TABLE</literal> and <literal>DROP TABLE</literal> operations are
   transactional, so the table will start or stop replicating at the correct
   snapshot once the transaction has committed.
  </para>

  <sect2 id="logical-replication-publication-replica-identity">
   <title>Replica Identity</title>

   <para>
    A published table must have a <firstterm>replica identity</firstterm>
    configured in order to be able to replicate <command>UPDATE</command>
    and <command>DELETE</command> operations, so that appropriate rows to
    update or delete can be identified on the subscriber side.
   </para>

   <para>
    By default, this is the primary key, if there is one. Another unique index
    (with certain additional requirements) can also be set to be the replica
    identity.  If the table does not have any suitable key, then it can be set
    to replica identity <literal>FULL</literal>, which means the entire row
    becomes the key.  When replica 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>