|
124 | 124 | </para>
|
125 | 125 |
|
126 | 126 | <para>
|
127 |
| - A published table must have a <quote>replica identity</quote> configured in |
| 127 | + A published table must have a <firstterm>replica identity</firstterm> configured in |
128 | 128 | order to be able to replicate <command>UPDATE</command>
|
129 | 129 | and <command>DELETE</command> operations, so that appropriate rows to
|
130 | 130 | update or delete can be identified on the subscriber side. By default,
|
131 | 131 | this is the primary key, if there is one. Another unique index (with
|
132 | 132 | certain additional requirements) can also be set to be the replica
|
133 | 133 | identity. If the table does not have any suitable key, then it can be set
|
134 |
| - to replica identity <quote>full</quote>, which means the entire row becomes |
135 |
| - the key. When replica identity <quote>full</quote> is specified, |
| 134 | + to replica identity <literal>FULL</literal>, which means the entire row becomes |
| 135 | + the key. When replica identity <literal>FULL</literal> is specified, |
136 | 136 | indexes can be used on the subscriber side for searching the rows. Candidate
|
137 | 137 | indexes must be btree, non-partial, and have at least one column reference
|
138 | 138 | (i.e. cannot consist of only expressions). These restrictions
|
139 | 139 | on the non-unique index properties adhere to some of the restrictions that
|
140 | 140 | are enforced for primary keys. If there are no such suitable indexes,
|
141 | 141 | the search on the subscriber side can be very inefficient, therefore
|
142 |
| - replica identity <quote>full</quote> should only be used as a |
| 142 | + replica identity <literal>FULL</literal> should only be used as a |
143 | 143 | fallback if no other solution is possible. If a replica identity other
|
144 |
| - than <quote>full</quote> is set on the publisher side, a replica identity |
| 144 | + than <literal>FULL</literal> is set on the publisher side, a replica identity |
145 | 145 | comprising the same or fewer columns must also be set on the subscriber
|
146 | 146 | side. See <xref linkend="sql-altertable-replica-identity"/> for details on
|
147 | 147 | 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
|
1640 | 1640 | <para>
|
1641 | 1641 | Logical replication is built with an architecture similar to physical
|
1642 | 1642 | streaming replication (see <xref linkend="streaming-replication"/>). It is
|
1643 |
| - implemented by <quote>walsender</quote> and <quote>apply</quote> |
| 1643 | + implemented by <literal>walsender</literal> and <literal>apply</literal> |
1644 | 1644 | processes. The walsender process starts logical decoding (described
|
1645 | 1645 | in <xref linkend="logicaldecoding"/>) of the WAL and loads the standard
|
1646 | 1646 | logical decoding plugin (pgoutput). The plugin transforms the changes read
|
|
0 commit comments