Re: [HACKERS] logical-replication.sgml improvements

[Peter Eisentraut]

On 1/20/17 11:00 AM, Erik Rijkers wrote:
> logical-replication.sgml.diff changes

Committed, thanks!

-- 
Peter Eisentraut  http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] logical-replication.sgml improvements

[Erik Rijkers]

On 2017-01-24 17:29, Robert Haas wrote:

On Fri, Jan 20, 2017 at 11:00 AM, Erik Rijkers  wrote:

logical-replication.sgml.diff changes


I had a look at this but these are not all open-and-shut cases.  In
many cases I think your proposed wording is better, but it's probably
a good idea for the people who were involved in the development of the
logical replication feature to have a look at it just to see if there
is anything with which they'd like to disagree.



Fair enough.

I agree that most changes are arguable - it fixes really only one real 
error:


   
Subscriptions are not dumped by pg_dump by 
default but

-   can be requested using the command-line
-   option --subscriptions.
+   this can be requested using the command-line
+   option --include-subscriptions.
   


thanks,

Erik Rijkers


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] logical-replication.sgml improvements

[Robert Haas]

On Fri, Jan 20, 2017 at 11:00 AM, Erik Rijkers  wrote:
> logical-replication.sgml.diff changes

I had a look at this but these are not all open-and-shut cases.  In
many cases I think your proposed wording is better, but it's probably
a good idea for the people who were involved in the development of the
logical replication feature to have a look at it just to see if there
is anything with which they'd like to disagree.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] logical-replication.sgml improvements

[Erik Rijkers]

logical-replication.sgml.diff changes

Erik Rijkers--- doc/src/sgml/logical-replication.sgml.orig	2017-01-20 16:46:25.0 +0100
+++ doc/src/sgml/logical-replication.sgml	2017-01-20 16:46:55.0 +0100
@@ -24,7 +24,7 @@
  
 
  
-  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 @@
 

 
- Firing triggers for individual changes as they are incoming to
+ Firing triggers for individual changes as they arrive on the
  subscriber.
 

@@ -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.
  
 
  
   Publication
 
   
-   A publication object can be defined on any physical
+   A publication can be defined on any physical
replication master.  The node where a publication is defined is referred to
as publisher.  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.
   
 
   
@@ -105,9 +105,9 @@
   
 
   
-   Publications can choose to limit the changes they produce to show
+   Publications can choose to limit the changes they produce to
any combination of INSERT, UPDATE, and
-   DELETE in a similar way to the way triggers are fired by
+   DELETE, similar to how triggers are fired by
particular event types.  If a table without a REPLICA
IDENTITY is added to a publication that
replicates UPDATE or DELETE
@@ -121,7 +121,7 @@
 
   
A publication is created using the 
-   command and may be later altered or dropped using corresponding commands.
+   command and may later be altered or dropped using corresponding commands.
   
 
   
@@ -141,7 +141,7 @@
replication.  The node where a subscription is defined is referred to as
the subscriber.  Subscription defines the connection
to another database and set of publications (one or more) to which it wants
-   to be subscribed.
+   to subscribe.
   
 
   
@@ -153,7 +153,7 @@
   
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.
   
 
@@ -164,8 +164,8 @@
 
   
Subscriptions are not dumped by pg_dump by default but
-   can be requested using the command-line
-   option --subscriptions.
+   this can be requested using the command-line
+   option --include-subscriptions.
   
 
   
@@ -183,7 +183,7 @@
 
   
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.
   
 
@@ -203,9 +203,9 @@
   Conflicts
 
   
-   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 conflict.  When
replicating UPDATE or DELETE
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 
pg_replication_origin_advance() function with
-   a node_name corresponding to the subscription name.
-   The current position of origins can be seen in the
+   a node_name corresponding to the subscription name,
+   and a position.  The current position of origins can be seen in the

pg_replication_origin_status system view.
   
@@ -246,8 +246,8 @@
   
Logical replication is built with an architecture