mirror of
https://github.com/postgres/postgres.git
synced 2026-05-21 09:48:06 -04:00
doc: Fix grammar in some logical replication pages
Author: Peter Smith <smithpb2250@gmail.com> Discussion: https://postgr.es/m/CAHut+PuvY_wYLPJ4DTs7NE9Lu2ty4d-OgZAOJC-NvCM=2wwcQQ@mail.gmail.com Backpatch-through: 14
This commit is contained in:
parent
8a431b6d67
commit
4fe7bac347
3 changed files with 10 additions and 10 deletions
|
|
@ -68,7 +68,7 @@
|
|||
<listitem>
|
||||
<para>
|
||||
Replicating between PostgreSQL instances on different platforms (for
|
||||
example Linux to Windows)
|
||||
example Linux to Windows).
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
|
|
@ -89,7 +89,7 @@
|
|||
<para>
|
||||
The subscriber database behaves in the same way as any other PostgreSQL
|
||||
instance and can be used as a publisher for other databases by defining its
|
||||
own publications. When the subscriber is treated as read-only by
|
||||
own publications. When the subscriber is treated as read-only by an
|
||||
application, there will be no conflicts from a single subscription. On the
|
||||
other hand, if there are other writes done either by an application or by other
|
||||
subscribers to the same set of tables, conflicts can arise.
|
||||
|
|
@ -202,8 +202,8 @@
|
|||
A <firstterm>subscription</firstterm> is the downstream side of logical
|
||||
replication. The node where a subscription is defined is referred to as
|
||||
the <firstterm>subscriber</firstterm>. A subscription defines the connection
|
||||
to another database and set of publications (one or more) to which it wants
|
||||
to subscribe.
|
||||
to another database and the set of publications (one or more) to which it
|
||||
wants to subscribe.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
|
|
@ -977,7 +977,7 @@ HINT: To initiate replication, you must manually create the replication slot, e
|
|||
|
||||
<note>
|
||||
<para>
|
||||
If the subscriber is in a release prior to 15, copy pre-existing data
|
||||
If the subscriber is in a release prior to 15, copying pre-existing data
|
||||
doesn't use row filters even if they are defined in the publication.
|
||||
This is because old releases can only copy the entire table data.
|
||||
</para>
|
||||
|
|
@ -2188,7 +2188,7 @@ CONTEXT: processing remote data for replication origin "pg_16395" during "INSER
|
|||
<sect2 id="logical-replication-snapshot">
|
||||
<title>Initial Snapshot</title>
|
||||
<para>
|
||||
The initial data in existing subscribed tables are snapshotted and
|
||||
The initial data in existing subscribed tables is snapshotted and
|
||||
copied in parallel instances of a special kind of apply process.
|
||||
These special apply processes are dedicated table synchronization
|
||||
workers, spawned for each table to be synchronized. Each table
|
||||
|
|
|
|||
|
|
@ -272,7 +272,7 @@ ALTER SUBSCRIPTION <replaceable class="parameter">name</replaceable> RENAME TO <
|
|||
process reports an error if any prepared transactions done by the
|
||||
logical replication worker (from when <literal>two_phase</literal>
|
||||
parameter was still <literal>true</literal>) are found. You can resolve
|
||||
prepared transactions on the publisher node, or manually roll back them
|
||||
prepared transactions on the publisher node, or manually roll them back
|
||||
on the subscriber, and then try again. The transactions prepared by
|
||||
logical replication worker corresponding to a particular subscription have
|
||||
the following pattern: <quote><literal>pg_gid_%u_%u</literal></quote>
|
||||
|
|
|
|||
|
|
@ -155,7 +155,7 @@ CREATE PUBLICATION <replaceable class="parameter">name</replaceable>
|
|||
</para>
|
||||
|
||||
<para>
|
||||
When a partitioned table is published via schema level publication, all
|
||||
When a partitioned table is published via a schema-level publication, all
|
||||
of its existing and future partitions are implicitly considered to be part of the
|
||||
publication, regardless of whether they are from the publication schema or not.
|
||||
So, even operations that are performed directly on a
|
||||
|
|
@ -178,7 +178,7 @@ CREATE PUBLICATION <replaceable class="parameter">name</replaceable>
|
|||
<listitem>
|
||||
<para>
|
||||
This parameter determines which DML operations will be published by
|
||||
the new publication to the subscribers. The value is
|
||||
the new publication to the subscribers. The value is a
|
||||
comma-separated list of operations. The allowed operations are
|
||||
<literal>insert</literal>, <literal>update</literal>,
|
||||
<literal>delete</literal>, and <literal>truncate</literal>.
|
||||
|
|
@ -218,7 +218,7 @@ CREATE PUBLICATION <replaceable class="parameter">name</replaceable>
|
|||
<note>
|
||||
<para>
|
||||
If the subscriber is from a release prior to 18, then initial table
|
||||
synchronization won't copy generated columns even if parameter
|
||||
synchronization won't copy generated columns even if the parameter
|
||||
<literal>publish_generated_columns</literal> is <literal>stored</literal>
|
||||
in the publisher.
|
||||
</para>
|
||||
|
|
|
|||
Loading…
Reference in a new issue