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 combination of
DELETE, 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
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
operations will cause an error on the publisher.
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
ALTER 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.