Do some copy-editing on the docs for replication origins.

Minor grammar and markup improvements.

diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index da59c0763766fdb61f43a74e4459be5eee6bb97c..a520a14cab3b0d58a87ab909f11b81ddddc8b1e0 100644 (file)
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -17192,7 +17192,8 @@ postgres=# SELECT * FROM pg_xlogfile_name_offset(pg_stop_backup());
     in  are for
     controlling and interacting with replication features.
     See ,
-    , 
+    , and
+    
     for information about the underlying features.  Use of these
     functions is restricted to superusers.
    
@@ -17203,9 +17204,11 @@ postgres=# SELECT * FROM pg_xlogfile_name_offset(pg_stop_backup());
    
 
    
-    The functions described in , 
-    linkend="functions-recovery-control">, and 
-    linkend="functions-admin-backup"> are also relevant for replication.
+    The functions described in
+    ,
+    , and
+    
+    are also relevant for replication.
    
 
    
@@ -17360,11 +17363,11 @@ postgres=# SELECT * FROM pg_xlogfile_name_offset(pg_stop_backup());
         pg_replication_origin_create(node_name text)
        
        
-        <parameter>internal_id <type>oid
+        oid
        
        
-        Create a replication origin with the passed in external
-        name, and create an internal id for it.
+        Create a replication origin with the given external
+        name, and return the internal id assigned to it.
        
       
 
@@ -17379,7 +17382,7 @@ postgres=# SELECT * FROM pg_xlogfile_name_offset(pg_stop_backup());
         void
        
        
-        Delete a previously created replication origin, including the
+        Delete a previously created replication origin, including any
         associated replay progress.
        
       
@@ -17392,10 +17395,10 @@ postgres=# SELECT * FROM pg_xlogfile_name_offset(pg_stop_backup());
         pg_replication_origin_oid(node_name text)
        
        
-        <parameter>internal_id <type>oid
+        oid
        
        
-        Lookup replication origin by name and return the internal id. If no
+        Lookup a replication origin by name and return the internal id. If no
         corresponding replication origin is found an error is thrown.
        
       
@@ -17411,7 +17414,7 @@ postgres=# SELECT * FROM pg_xlogfile_name_offset(pg_stop_backup());
         void
        
        
-        Configure the current session to be replaying from the passed in
+        Mark the current session as replaying from the given
         origin, allowing replay progress to be tracked.  Use
         pg_replication_origin_session_reset to revert.
         Can only be used if no previous origin is configured.
@@ -17442,7 +17445,7 @@ postgres=# SELECT * FROM pg_xlogfile_name_offset(pg_stop_backup());
         pg_replication_origin_session_is_setup()
        
        
-        bool
+        bool
        
        
         Has a replication origin been configured in the current session?
@@ -17457,7 +17460,7 @@ postgres=# SELECT * FROM pg_xlogfile_name_offset(pg_stop_backup());
         pg_replication_origin_session_progress(flush bool)
        
        
-        pg_lsn
+        pg_lsn
        
        
         Return the replay position for the replication origin configured in
@@ -17478,8 +17481,8 @@ postgres=# SELECT * FROM pg_xlogfile_name_offset(pg_stop_backup());
         void
        
        
-        Mark the current transaction to be replaying a transaction that has
-        committed at the passed in LSN and timestamp. Can
+        Mark the current transaction as replaying a transaction that has
+        committed at the given LSN and timestamp. Can
         only be called when a replication origin has previously been
         configured using
         pg_replication_origin_session_setup().
@@ -17513,7 +17516,7 @@ postgres=# SELECT * FROM pg_xlogfile_name_offset(pg_stop_backup());
         void
        
        
-        Set replication progress for the passed in node to the passed in
+        Set replication progress for the given node to the given
         position. This primarily is useful for setting up the initial position
         or a new position after configuration changes and similar. Be aware
         that careless use of this function can lead to inconsistently
@@ -17529,10 +17532,10 @@ postgres=# SELECT * FROM pg_xlogfile_name_offset(pg_stop_backup());
         pg_replication_origin_progress(node_name text, flush bool)
        
        
-        pg_lsn
+        pg_lsn
        
        
-        Return the replay position for the passed in replication origin. The
+        Return the replay position for the given replication origin. The
         parameter flush determines whether the
         corresponding local transaction will be guaranteed to have been
         flushed to disk or not.


diff --git a/doc/src/sgml/replication-origins.sgml b/doc/src/sgml/replication-origins.sgml

index a7e8d40cf23627376c169e1cbfbbb1eed54a499c..fdc41c99d772161c3cbace97b305b161e133b05e 100644 (file)

--- a/doc/src/sgml/replication-origins.sgml
+++ b/doc/src/sgml/replication-origins.sgml
@@ -1,6 +1,7 @@
 
 
  Replication Progress Tracking
+
  
   Replication Progress Tracking
  
@@ -11,46 +12,48 @@
  
   Replication origins are intended to make it easier to implement
   logical replication solutions on top
-  of <xref linkend="logicaldecoding">. They provide a solution to two
-  common problems:
+  of <link linkend="logicaldecoding">logical decoding.
+  They provide a solution to two common problems:
   
-   How to safely keep track of replication progress
-   How to change replication behavior, based on the
-   origin of a row; e.g. to avoid loops in bi-directional replication
-   setups
+   
+    How to safely keep track of replication progress
+   
+   
+    How to change replication behavior based on the
+     origin of a row; for example, to prevent loops in bi-directional
+     replication setups
+   
   
  
 
  
-  Replication origins consist out of a name and an oid. The name,
+  Replication origins have just two properties, a name and an OID. The name,
   which is what should be used to refer to the origin across systems, is
   free-form text. It should be used in a way that makes conflicts
   between replication origins created by different replication solutions
   unlikely; e.g. by prefixing the replication solution's name to it.
-  The oid is used only to avoid having to store the long version
+  The OID is used only to avoid having to store the long version
   in situations where space efficiency is important. It should never be shared
-  between systems.
+  across systems.
  
 
  
-  Replication origins can be created using the
+  Replication origins can be created using the function
   pg_replication_origin_create();
   dropped using
   pg_replication_origin_drop();
   and seen in the
   pg_replication_origin
-  catalog.
+  system catalog.
  
 
  
-  When replicating from one system to another (independent of the fact that
-  those two might be in the same cluster, or even same database) one
-  nontrivial part of building a replication solution is to keep track of
+  One nontrivial part of building a replication solution is to keep track of
   replay progress in a safe manner. When the applying process, or the whole
   cluster, dies, it needs to be possible to find out up to where data has
-  successfully been replicated. Naive solutions to this like updating a row in
-  a table for every replayed transaction have problems like run-time overhead
-  bloat.
+  successfully been replicated. Naive solutions to this, such as updating a
+  row in a table for every replayed transaction, have problems like run-time
+  overhead and database bloat.
  
 
  
@@ -74,20 +77,20 @@
  
 
  
-  In more complex replication topologies than replication from exactly one
-  system to one other, another problem can be that it is hard to avoid
+  In replication topologies more complex than replication from exactly one
+  system to one other system, another problem can be that it is hard to avoid
   replicating replayed rows again. That can lead both to cycles in the
   replication and inefficiencies. Replication origins provide an optional
   mechanism to recognize and prevent that. When configured using the functions
   referenced in the previous paragraph, every change and transaction passed to
   output plugin callbacks (see )
   generated by the session is tagged with the replication origin of the
-  generating session.  This allows to treat them differently in the output
-  plugin, e.g. ignoring all but locally originating rows.  Additionally
+  generating session.  This allows treating them differently in the output
+  plugin, e.g. ignoring all but locally-originating rows.  Additionally
   the 
   filter_by_origin_cb callback can be used
   to filter the logical decoding change stream based on the
   source. While less flexible, filtering via that callback is
-  considerably more efficient.
+  considerably more efficient than doing it in the output plugin.
  
 

diff --git a/doc/src/sgml/replication-origins.sgml b/doc/src/sgml/replication-origins.sgml
index a7e8d40cf23627376c169e1cbfbbb1eed54a499c..fdc41c99d772161c3cbace97b305b161e133b05e 100644 (file)
--- a/doc/src/sgml/replication-origins.sgml
+++ b/doc/src/sgml/replication-origins.sgml
@@ -1,6 +1,7 @@
 
 
  Replication Progress Tracking
+
  
   Replication Progress Tracking
  
@@ -11,46 +12,48 @@
  
   Replication origins are intended to make it easier to implement
   logical replication solutions on top
-  of <xref linkend="logicaldecoding">. They provide a solution to two
-  common problems:
+  of <link linkend="logicaldecoding">logical decoding.
+  They provide a solution to two common problems:
   
-   How to safely keep track of replication progress
-   How to change replication behavior, based on the
-   origin of a row; e.g. to avoid loops in bi-directional replication
-   setups
+   
+    How to safely keep track of replication progress
+   
+   
+    How to change replication behavior based on the
+     origin of a row; for example, to prevent loops in bi-directional
+     replication setups
+   
   
  
 
  
-  Replication origins consist out of a name and an oid. The name,
+  Replication origins have just two properties, a name and an OID. The name,
   which is what should be used to refer to the origin across systems, is
   free-form text. It should be used in a way that makes conflicts
   between replication origins created by different replication solutions
   unlikely; e.g. by prefixing the replication solution's name to it.
-  The oid is used only to avoid having to store the long version
+  The OID is used only to avoid having to store the long version
   in situations where space efficiency is important. It should never be shared
-  between systems.
+  across systems.
  
 
  
-  Replication origins can be created using the
+  Replication origins can be created using the function
   pg_replication_origin_create();
   dropped using
   pg_replication_origin_drop();
   and seen in the
   pg_replication_origin
-  catalog.
+  system catalog.
  
 
  
-  When replicating from one system to another (independent of the fact that
-  those two might be in the same cluster, or even same database) one
-  nontrivial part of building a replication solution is to keep track of
+  One nontrivial part of building a replication solution is to keep track of
   replay progress in a safe manner. When the applying process, or the whole
   cluster, dies, it needs to be possible to find out up to where data has
-  successfully been replicated. Naive solutions to this like updating a row in
-  a table for every replayed transaction have problems like run-time overhead
-  bloat.
+  successfully been replicated. Naive solutions to this, such as updating a
+  row in a table for every replayed transaction, have problems like run-time
+  overhead and database bloat.
  
 
  
@@ -74,20 +77,20 @@
  
 
  
-  In more complex replication topologies than replication from exactly one
-  system to one other, another problem can be that it is hard to avoid
+  In replication topologies more complex than replication from exactly one
+  system to one other system, another problem can be that it is hard to avoid
   replicating replayed rows again. That can lead both to cycles in the
   replication and inefficiencies. Replication origins provide an optional
   mechanism to recognize and prevent that. When configured using the functions
   referenced in the previous paragraph, every change and transaction passed to
   output plugin callbacks (see )
   generated by the session is tagged with the replication origin of the
-  generating session.  This allows to treat them differently in the output
-  plugin, e.g. ignoring all but locally originating rows.  Additionally
+  generating session.  This allows treating them differently in the output
+  plugin, e.g. ignoring all but locally-originating rows.  Additionally
   the 
   filter_by_origin_cb callback can be used
   to filter the logical decoding change stream based on the
   source. While less flexible, filtering via that callback is
-  considerably more efficient.
+  considerably more efficient than doing it in the output plugin.