Copy editing of the replication origins patch.

Michael Paquier and myself.

doc/src/sgml/func.sgml

@@ -17086,9 +17086,8 @@ postgres=# SELECT * FROM pg_xlogfile_name_offset(pg_stop_backup());
         <parameter>internal_id</parameter> <type>oid</type>
        </entry>
        <entry>
-        Lookup replication origin by name and return the internal
-        oid. If no corresponding replication origin is found a error
-        is thrown.
+        Lookup replication origin by name and return the internal id. If no
+        corresponding replication origin is found an error is thrown.
        </entry>
       </row>
 

doc/src/sgml/replication-origins.sgml

@@ -22,14 +22,14 @@
  </para>
 
  <para>
-  Replication origins consist out of a name and a 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 in situations where space efficiency is important. It should
-  never be shared between systems.
+  Replication origins consist out of a name and an <type>oid</type>. The name,
+  which is what should be used to refer to the origin across systems, is
+  free-form <type>text</type>. 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 <type>oid</type> 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.
  </para>
 
  <para>
@@ -61,11 +61,11 @@
   timestamp of every source transaction can be configured on a per
   transaction basis using
   <link linkend="pg-replication-origin-xact-setup"><function>pg_replication_origin_xact_setup()</function></link>.
-  If that's done replication progress will be persist in a crash safe
+  If that's done replication progress will persist in a crash safe
   manner. Replay progress for all replication origins can be seen in the
   <link linkend="catalog-pg-replication-origin-status">
    <structname>pg_replication_origin_status</structname>
-  </link> view. A individual origin's progress, e.g. when resuming
+  </link> view. An individual origin's progress, e.g. when resuming
   replication, can be acquired using
   <link linkend="pg-replication-origin-progress"><function>pg_replication_origin_progress()</function></link>
   for any origin or
@@ -75,9 +75,9 @@
 
  <para>
   In more complex replication topologies than replication from exactly one
-  system to one other, another problem can be that, that it is hard to avoid
+  system to one other, 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 a optional
+  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 <xref linkend="logicaldecoding-output-plugin">)

src/backend/replication/logical/origin.c

@@ -12,7 +12,7 @@
  *
  * This file provides the following:
  * * An infrastructure to name nodes in a replication setup
- * * A facility to efficiently store and persist replication progress in a
+ * * A facility to efficiently store and persist replication progress in an
  *   efficient and durable manner.
  *
  * Replication origin consist out of a descriptive, user defined, external
@@ -44,14 +44,14 @@
  *
  * There are several levels of locking at work:
  *
- * * To create and drop replication origins a exclusive lock on
+ * * To create and drop replication origins an exclusive lock on
  *   pg_replication_slot is required for the duration. That allows us to
  *   safely and conflict free assign new origins using a dirty snapshot.
  *
- * * When creating a in-memory replication progress slot the ReplicationOirgin
+ * * When creating an in-memory replication progress slot the ReplicationOirgin
  *   LWLock has to be held exclusively; when iterating over the replication
  *   progress a shared lock has to be held, the same when advancing the
- *   replication progress of a individual backend that has not setup as the
+ *   replication progress of an individual backend that has not setup as the
  *   session's replication origin.
  *
  * * When manipulating or looking at the remote_lsn and local_lsn fields of a
@@ -251,7 +251,7 @@ replorigin_create(char *roname)
 	 * We need the numeric replication origin to be 16bit wide, so we cannot
 	 * rely on the normal oid allocation. Instead we simply scan
 	 * pg_replication_origin for the first unused id. That's not particularly
-	 * efficient, but this should be an fairly infrequent operation - we can
+	 * efficient, but this should be a fairly infrequent operation - we can
 	 * easily spend a bit more code on this when it turns out it needs to be
 	 * faster.
 	 *
@@ -1078,7 +1078,7 @@ replorigin_session_setup(RepOriginId node)
 /*
  * Reset replay state previously setup in this session.
  *
- * This function may only be called if a origin was setup with
+ * This function may only be called if an origin was setup with
  * replorigin_session_setup().
  */
 void
@@ -1121,7 +1121,7 @@ replorigin_session_advance(XLogRecPtr remote_commit, XLogRecPtr local_commit)
 
 /*
  * Ask the machinery about the point up to which we successfully replayed
- * changes from a already setup replication origin.
+ * changes from an already setup replication origin.
  */
 XLogRecPtr
 replorigin_session_get_progress(bool flush)

src/include/catalog/pg_replication_origin.h

@@ -34,7 +34,7 @@ CATALOG(pg_replication_origin,6000) BKI_SHARED_RELATION BKI_WITHOUT_OIDS
 	 *
 	 * This should never leave the system.
 	 *
-	 * Needs to fit into a uint16, so we don't waste too much space in WAL
+	 * Needs to fit into an uint16, so we don't waste too much space in WAL
 	 * records. For this reason we don't use a normal Oid column here, since
 	 * we need to handle allocation of new values manually.
 	 */