logical-replication.sgml.diff changes
Erik Rijkers
--- doc/src/sgml/logical-replication.sgml.orig 2017-01-20 16:46:25.000000000 +0100
+++ doc/src/sgml/logical-replication.sgml 2017-01-20 16:46:55.000000000 +0100
@@ -24,7 +24,7 @@
</para>
<para>
- Logical replication sends the changes on the publisher to the subscriber as
+ Logical replication sends changes on the publisher to the subscriber as
they occur in real-time. The subscriber applies the data in the same order
as the publisher so that transactional consistency is guaranteed for
publications within a single subscription. This method of data replication
@@ -44,7 +44,7 @@
<listitem>
<para>
- Firing triggers for individual changes as they are incoming to
+ Firing triggers for individual changes as they arrive on the
subscriber.
</para>
</listitem>
@@ -81,19 +81,19 @@
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
application, there will be no conflicts from a single subscription. On the
- other hand, if there are other writes done either by application or other
- subscribers to the same set of tables conflicts can arise.
+ 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.
</para>
<sect1 id="logical-replication-publication">
<title>Publication</title>
<para>
- A <firstterm>publication</firstterm> object can be defined on any physical
+ A <firstterm>publication</firstterm> can be defined on any physical
replication master. The node where a publication is defined is referred to
as <firstterm>publisher</firstterm>. A publication is a set of changes
- generated from a group of tables, and might also be described as a change
- set or replication set. Each publication exists in only one database.
+ generated from a table or a group of tables, and might also be described as
+ a change set or replication set. Each publication exists in only one database.
</para>
<para>
@@ -105,9 +105,9 @@
</para>
<para>
- Publications can choose to limit the changes they produce to show
+ Publications can choose to limit the changes they produce to
any combination of <command>INSERT</command>, <command>UPDATE</command>, and
- <command>DELETE</command> in a similar way to the way triggers are fired by
+ <command>DELETE</command>, similar to how triggers are fired by
particular event types. If a table without a <literal>REPLICA
IDENTITY</literal> is added to a publication that
replicates <command>UPDATE</command> or <command>DELETE</command>
@@ -121,7 +121,7 @@
<para>
A publication is created using the <xref linkend="sql-createpublication">
- command and may be later altered or dropped using corresponding commands.
+ command and may later be altered or dropped using corresponding commands.
</para>
<para>
@@ -141,7 +141,7 @@
replication. The node where a subscription is defined is referred to as
the <firstterm>subscriber</firstterm>. Subscription defines the connection
to another database and set of publications (one or more) to which it wants
- to be subscribed.
+ to subscribe.
</para>
<para>
@@ -153,7 +153,7 @@
<para>
A subscriber node may have multiple subscriptions if desired. It is
possible to define multiple subscriptions between a single
- publisher-subscriber pair, in which case extra care must be taken to ensure
+ publisher-subscriber pair, in which case care must be taken to ensure
that the subscribed publication objects don't overlap.
</para>
@@ -164,8 +164,8 @@
<para>
Subscriptions are not dumped by <command>pg_dump</command> by default but
- can be requested using the command-line
- option <option>--subscriptions</option>.
+ this can be requested using the command-line
+ option <option>--include-subscriptions</option>.
</para>
<para>
@@ -183,7 +183,7 @@
<para>
The schema definitions are not replicated and the published tables must
- exist on the subsriber for replication to work. Only regular tables may be
+ exist on the subscriber. Only regular tables may be
the target of replication. For example, you can't replicate to a view.
</para>
@@ -203,9 +203,9 @@
<title>Conflicts</title>
<para>
- The logical replication behaves similarly to normal DML operations in that
+ Logical replication behaves similarly to normal DML operations in that
the data will be updated even if it was changed locally on the subscriber
- node. If the incoming data violates any constraints the replication will
+ node. If incoming data violates any constraints the replication will
stop. This is referred to as a <firstterm>conflict</firstterm>. When
replicating <command>UPDATE</command> or <command>DELETE</command>
operations, missing data will not produce a conflict and such operations
@@ -224,8 +224,8 @@
transaction that conflicts with the existing data. The transaction can be
skipped by calling the <link linkend="pg-replication-origin-advance">
<function>pg_replication_origin_advance()</function></link> function with
- a <parameter>node_name</parameter> corresponding to the subscription name.
- The current position of origins can be seen in the
+ a <parameter>node_name</parameter> corresponding to the subscription name,
+ and a position. The current position of origins can be seen in the
<link linkend="view-pg-replication-origin-status">
<structname>pg_replication_origin_status</structname></link> system view.
</para>
@@ -246,8 +246,8 @@
<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 the <quote>apply</quote>
- processes. The walsender starts logical decoding (described
+ implemented by <quote>walsender</quote> and <quote>apply</quote>
+ 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
from WAL to the logical replication protocol
@@ -255,7 +255,7 @@
according to the publication specification. The data is then continuously
transferred using the streaming replication protocol to the apply worker,
which maps the data to local tables and applies the individual changes as
- they are received in exact transactional order.
+ they are received, in correct transactional order.
</para>
<para>
@@ -270,9 +270,9 @@
<title>Monitoring</title>
<para>
- Because logical replication is based on similar architecture as
- <link linkend="streaming-replication">physical streaming replication</link>
- the monitoring on a publication node is very similar to monitoring of
+ Because logical replication is based on a similar architecture as
+ <link linkend="streaming-replication">physical streaming replication</link>,
+ the monitoring on a publication node is similar to monitoring of a
physical replication master
(see <xref linkend="streaming-replication-monitoring">).
</para>
@@ -295,8 +295,8 @@
<title>Security</title>
<para>
- Logical replication connections occur in the same way as physical streaming
- replication. It requires access to be specifically given using
+ Logical replication connections occur in the same way as with physical streaming
+ replication. It requires access to be explicitly given using
<filename>pg_hba.conf</filename>. The role used for the replication
connection must have the <literal>REPLICATION</literal> attribute. This
gives a role access to both logical and physical replication.
@@ -333,7 +333,7 @@
<para>
On the publisher side, <varname>wal_level</varname> must be set to
<literal>logical</literal>, and <varname>max_replication_slots</varname>
- has to be set to at least the number of subscriptions expected to connect.
+ must be set to at least the number of subscriptions expected to connect.
And <varname>max_wal_senders</varname> should be set to at least the same
as <varname>max_replication_slots</varname> plus the number of physical replicas
that are connected at the same time.
@@ -343,7 +343,7 @@
The subscriber also requires the <varname>max_replication_slots</varname>
to be set. In this case it should be set to at least the number of
subscriptions that will be added to the subscriber.
- <varname>max_logical_replication_workers</varname> has to be set to at
+ <varname>max_logical_replication_workers</varname> must be set to at
least the number of subscriptions. Additionally the
<varname>max_worker_processes</varname> may need to be adjusted to
accommodate for replication workers, at least
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
