From 2b22795b32576fa7173b501b646581a17de35902 Mon Sep 17 00:00:00 2001
From: Andres Freund <andres@anarazel.de>
Date: Fri, 1 May 2015 12:22:13 +0200
Subject: Copy editing of the replication origins patch.

Michael Paquier and myself.
---
 doc/src/sgml/func.sgml                |  5 ++---
 doc/src/sgml/replication-origins.sgml | 24 ++++++++++++------------
 2 files changed, 14 insertions(+), 15 deletions(-)

(limited to 'doc/src')

diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index dcade93e439..056cff04e15 100644
--- a/doc/src/sgml/func.sgml
+++ b/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>
 
diff --git a/doc/src/sgml/replication-origins.sgml b/doc/src/sgml/replication-origins.sgml
index 0cd08ee6b5f..5a4b4cbe74f 100644
--- a/doc/src/sgml/replication-origins.sgml
+++ b/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">)
-- 
cgit v1.2.3