|
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