|
|
|
@ -124,24 +124,24 @@ |
|
|
|
|
</para> |
|
|
|
|
|
|
|
|
|
<para> |
|
|
|
|
A published table must have a <quote>replica identity</quote> configured in |
|
|
|
|
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. 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 <quote>full</quote>, which means the entire row becomes |
|
|
|
|
the key. When replica identity <quote>full</quote> is specified, |
|
|
|
|
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, non-partial, and have at least one column reference |
|
|
|
|
(i.e. cannot consist of only expressions). 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 <quote>full</quote> should only be used as a |
|
|
|
|
replica identity <literal>FULL</literal> should only be used as a |
|
|
|
|
fallback if no other solution is possible. If a replica identity other |
|
|
|
|
than <quote>full</quote> is set on the publisher side, a replica identity |
|
|
|
|
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. See <xref linkend="sql-altertable-replica-identity"/> for details on |
|
|
|
|
how to set the replica identity. If a table without a replica identity is |
|
|
|
@ -1640,7 +1640,7 @@ CONTEXT: processing remote data for replication origin "pg_16395" during "INSER |
|
|
|
|
<para> |
|
|
|
|
Logical replication is built with an architecture similar to physical |
|
|
|
|
streaming replication (see <xref linkend="streaming-replication"/>). It is |
|
|
|
|
implemented by <quote>walsender</quote> and <quote>apply</quote> |
|
|
|
|
implemented by <literal>walsender</literal> and <literal>apply</literal> |
|
|
|
|
processes. The walsender process starts logical decoding (described |
|
|
|
|
in <xref linkend="logicaldecoding"/>) of the WAL and loads the standard |
|
|
|
|
logical decoding plugin (pgoutput). The plugin transforms the changes read |
|
|
|
|