]> git.ipfire.org Git - thirdparty/postgresql.git/commitdiff
doc: Fix grammar in some logical replication pages
authorMichael Paquier <michael@paquier.xyz>
Mon, 27 Apr 2026 07:17:26 +0000 (16:17 +0900)
committerMichael Paquier <michael@paquier.xyz>
Mon, 27 Apr 2026 07:17:26 +0000 (16:17 +0900)
Author: Peter Smith <smithpb2250@gmail.com>
Discussion: https://postgr.es/m/CAHut+PuvY_wYLPJ4DTs7NE9Lu2ty4d-OgZAOJC-NvCM=2wwcQQ@mail.gmail.com
Backpatch-through: 14

doc/src/sgml/logical-replication.sgml
doc/src/sgml/ref/create_publication.sgml

index db68cc6ec1dd66a3517010dcd7c0c19aeab4c6a4..7117275250638e8889eb69af838f10f11b2de829 100644 (file)
@@ -67,7 +67,7 @@
    <listitem>
     <para>
      Replicating between PostgreSQL instances on different platforms (for
-     example Linux to Windows)
+     example Linux to Windows).
     </para>
    </listitem>
 
@@ -88,7 +88,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.
    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>
@@ -982,7 +982,7 @@ test_standby=# SELECT slot_name, (synced AND NOT temporary AND invalidation_reas
 
    <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>
@@ -1831,7 +1831,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 a parallel instance of a special kind of apply process.
      This process will create its own replication slot and copy the existing
      data.  As soon as the copy is finished the table contents will become
index 71971fc27d52901a9f1409949dd6398a20a989d9..e42069c20a46c13f719cdbb206d4a74529d6f411 100644 (file)
@@ -152,7 +152,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
@@ -175,7 +175,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>.