doc: Fix some markups in logical replication section
Author: Peter Smith Reviewed-by: David Zhang Discussion: https://postgr.es/m/CAHut+Pst11ac2hcmePt1=oTmBwTT=DAssRR1nsdoy4BT+68=Mg@mail.gmail.com
This commit is contained in:
parent
90f0d28814
commit
0890f7d528
@ -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
|
||||
|
Loading…
x
Reference in New Issue
Block a user