doc: Fix grammar in some logical replication pages

Author: Peter Smith <smithpb2250@gmail.com>
Discussion: https://postgr.es/m/CAHut+PuvY_wYLPJ4DTs7NE9Lu2ty4d-OgZAOJC-NvCM=2wwcQQ@mail.gmail.com
Backpatch-through: 14

diff --git a/doc/src/sgml/logical-replication.sgml b/doc/src/sgml/logical-replication.sgml
index fd2edc1addb4b96f14f450af80465f97a7b44fc4..03e3ed9c1708e8ac1cc74f3fbf64d91d80742702 100644 (file)
--- a/doc/src/sgml/logical-replication.sgml
+++ b/doc/src/sgml/logical-replication.sgml
@@ -68,7 +68,7 @@
    <listitem>
     <para>
      Replicating between PostgreSQL instances on different platforms (for
-     example Linux to Windows)
+     example Linux to Windows).
     </para>
    </listitem>
 
@@ -89,7 +89,7 @@
  <para>
   The subscriber database behaves in the same way as any other PostgreSQL
   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
+  own publications.  When the subscriber is treated as read-only by an
   application, there will be no conflicts from a single subscription.  On the
   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.
@@ -202,8 +202,8 @@
    A <firstterm>subscription</firstterm> is the downstream side of logical
    replication.  The node where a subscription is defined is referred to as
    the <firstterm>subscriber</firstterm>.  A subscription defines the connection
-   to another database and set of publications (one or more) to which it wants
-   to subscribe.
+   to another database and the set of publications (one or more) to which it
+   wants to subscribe.
   </para>
 
   <para>
@@ -977,7 +977,7 @@ HINT:  To initiate replication, you must manually create the replication slot, e
 
    <note>
     <para>
-     If the subscriber is in a release prior to 15, copy pre-existing data
+     If the subscriber is in a release prior to 15, copying pre-existing data
      doesn't use row filters even if they are defined in the publication.
      This is because old releases can only copy the entire table data.
     </para>
@@ -2188,7 +2188,7 @@ CONTEXT:  processing remote data for replication origin "pg_16395" during "INSER
   <sect2 id="logical-replication-snapshot">
     <title>Initial Snapshot</title>
     <para>
-     The initial data in existing subscribed tables are snapshotted and
+     The initial data in existing subscribed tables is snapshotted and
      copied in parallel instances of a special kind of apply process.
      These special apply processes are dedicated table synchronization
      workers, spawned for each table to be synchronized.  Each table

diff --git a/doc/src/sgml/ref/alter_subscription.sgml b/doc/src/sgml/ref/alter_subscription.sgml
index fdc648d007f1cf348bb35d6735fc6e3b222e81af..1333a0b559f359ac77365de4b04a5e8e5125d744 100644 (file)
--- a/doc/src/sgml/ref/alter_subscription.sgml
+++ b/doc/src/sgml/ref/alter_subscription.sgml
@@ -272,7 +272,7 @@ ALTER SUBSCRIPTION <replaceable class="parameter">name</replaceable> RENAME TO <
       process reports an error if any prepared transactions done by the
       logical replication worker (from when <literal>two_phase</literal>
       parameter was still <literal>true</literal>) are found. You can resolve
-      prepared transactions on the publisher node, or manually roll back them
+      prepared transactions on the publisher node, or manually roll them back
       on the subscriber, and then try again. The transactions prepared by
       logical replication worker corresponding to a particular subscription have
       the following pattern: <quote><literal>pg_gid_%u_%u</literal></quote>

diff --git a/doc/src/sgml/ref/create_publication.sgml b/doc/src/sgml/ref/create_publication.sgml
index e83da50e4fe390e37812a555f637f612b66fcd87..b9e12a33c62c67d913e41784168ed63fca8a28f2 100644 (file)
--- a/doc/src/sgml/ref/create_publication.sgml
+++ b/doc/src/sgml/ref/create_publication.sgml
@@ -155,7 +155,7 @@ CREATE PUBLICATION <replaceable class="parameter">name</replaceable>
      </para>
 
      <para>
-      When a partitioned table is published via schema level publication, all
+      When a partitioned table is published via a schema-level publication, all
       of its existing and future partitions are implicitly considered to be part of the
       publication, regardless of whether they are from the publication schema or not.
       So, even operations that are performed directly on a
@@ -178,7 +178,7 @@ CREATE PUBLICATION <replaceable class="parameter">name</replaceable>
         <listitem>
          <para>
           This parameter determines which DML operations will be published by
-          the new publication to the subscribers.  The value is
+          the new publication to the subscribers.  The value is a
           comma-separated list of operations.  The allowed operations are
           <literal>insert</literal>, <literal>update</literal>,
           <literal>delete</literal>, and <literal>truncate</literal>.
@@ -218,7 +218,7 @@ CREATE PUBLICATION <replaceable class="parameter">name</replaceable>
          <note>
           <para>
            If the subscriber is from a release prior to 18, then initial table
-           synchronization won't copy generated columns even if parameter
+           synchronization won't copy generated columns even if the parameter
            <literal>publish_generated_columns</literal> is <literal>stored</literal>
            in the publisher.
           </para>