begriffs open source - ai-pg/blob - full-docs/txt/logical-replication-publication.txt

   1
   2 29.1. Publication #
   3
   4    29.1.1. Replica Identity
   5
   6    A publication can be defined on any physical replication primary. The
   7    node where a publication is defined is referred to as publisher. A
   8    publication is a set of changes generated from a table or a group of
   9    tables, and might also be described as a change set or replication set.
  10    Each publication exists in only one database.
  11
  12    Publications are different from schemas and do not affect how the table
  13    is accessed. Each table can be added to multiple publications if
  14    needed. Publications may currently only contain tables and all tables
  15    in schema. Objects must be added explicitly, except when a publication
  16    is created for ALL TABLES.
  17
  18    Publications can choose to limit the changes they produce to any
  19    combination of INSERT, UPDATE, DELETE, and TRUNCATE, similar to how
  20    triggers are fired by particular event types. By default, all operation
  21    types are replicated. These publication specifications apply only for
  22    DML operations; they do not affect the initial data synchronization
  23    copy. (Row filters have no effect for TRUNCATE. See Section 29.4).
  24
  25    Every publication can have multiple subscribers.
  26
  27    A publication is created using the CREATE PUBLICATION command and may
  28    later be altered or dropped using corresponding commands.
  29
  30    The individual tables can be added and removed dynamically using ALTER
  31    PUBLICATION. Both the ADD TABLE and DROP TABLE operations are
  32    transactional, so the table will start or stop replicating at the
  33    correct snapshot once the transaction has committed.
  34
  35 29.1.1. Replica Identity #
  36
  37    A published table must have a replica identity configured in order to
  38    be able to replicate UPDATE and DELETE operations, so that appropriate
  39    rows to update or delete can be identified on the subscriber side.
  40
  41    By default, this is the primary key, if there is one. Another unique
  42    index (with certain additional requirements) can also be set to be the
  43    replica identity. If the table does not have any suitable key, then it
  44    can be set to replica identity FULL, which means the entire row becomes
  45    the key. When replica identity FULL is specified, indexes can be used
  46    on the subscriber side for searching the rows. Candidate indexes must
  47    be btree or hash, non-partial, and the leftmost index field must be a
  48    column (not an expression) that references the published table column.
  49    These restrictions on the non-unique index properties adhere to some of
  50    the restrictions that are enforced for primary keys. If there are no
  51    such suitable indexes, the search on the subscriber side can be very
  52    inefficient, therefore replica identity FULL should only be used as a
  53    fallback if no other solution is possible.
  54
  55    If a replica identity other than FULL is set on the publisher side, a
  56    replica identity comprising the same or fewer columns must also be set
  57    on the subscriber side.
  58
  59    Tables with a replica identity defined as NOTHING, DEFAULT without a
  60    primary key, or USING INDEX with a dropped index, cannot support UPDATE
  61    or DELETE operations when included in a publication replicating these
  62    actions. Attempting such operations will result in an error on the
  63    publisher.
  64
  65    INSERT operations can proceed regardless of any replica identity.
  66
  67    See ALTER TABLE...REPLICA IDENTITY for details on how to set the
  68    replica identity.