A publication can be defined on any physical replication master. The node where a publication is defined is referred to as publisher. 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.
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. Objects must be added explicitly, except when a publication
is created for
Publications can choose to limit the changes they produce to any
similar to how triggers are fired by particular event types. By
default, all operation types are replicated.
A published table must have a “replica identity” configured in order to be
able to replicate
DELETE operations, so that appropriate
rows to update or delete can be identified on the subscriber side.
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 “full”, which means the
entire row becomes the key. This, however, is very inefficient and
should only be used as a fallback if no other solution is possible.
If a replica identity other than “full” is set on the publisher side, a replica
identity comprising the same or fewer columns must also be set on
the subscriber side. See
REPLICA IDENTITY for details on how to set the
replica identity. If a table without a replica identity is added to
a publication that replicates
DELETE operations then subsequent
DELETE operations will cause an error on the
INSERT operations can
proceed regardless of any replica identity.
Every publication can have multiple subscribers.
A publication is created using the CREATE PUBLICATION command and may later be altered or dropped using corresponding commands.
The individual tables can be added and removed dynamically using
PUBLICATION. Both the
DROP TABLE operations
are transactional; so the table will start or stop replicating at
the correct snapshot once the transaction has committed.
If you see anything in the documentation that is not correct, does not match your experience with the particular feature or requires further clarification, please use this form to report a documentation issue.