public inbox for [email protected]
help / color / mirror / Atom feedFrom: Peter Smith <[email protected]>
To: PostgreSQL Hackers <[email protected]>
To: Michael Paquier <[email protected]>
Subject: DOCS - typos and grammar issues across logical replication docs.
Date: Fri, 24 Apr 2026 15:32:24 +1000
Message-ID: <CAHut+PuvY_wYLPJ4DTs7NE9Lu2ty4d-OgZAOJC-NvCM=2wwcQQ@mail.gmail.com> (raw)
Hi.
(Unfortunately, I was too slow to make this patch, so I missed getting
these fixes into [1]).
I fed the logical replication online documentation into my favourite
AI tool to help me come up with the following patch that fixes many
minor issues (e.g., spelling, grammar, inconsistencies, vagueness,
etc.).
PSA v1.
======
[1] https://github.com/postgres/postgres/commit/d3bba041543593eb5341683107d899734dc8e73e
Kind Regards,
Peter Smith.
Fujitsu Australia
Attachments:
[application/octet-stream] v1-0001-DOCS-logical-replication-many-little-fixes.patch (10.9K, 2-v1-0001-DOCS-logical-replication-many-little-fixes.patch)
download | inline diff:
From 9d5db2f977b305a2a40e7b0d5cb33ba1875cab32 Mon Sep 17 00:00:00 2001
From: Peter Smith <[email protected]>
Date: Fri, 24 Apr 2026 15:22:04 +1000
Subject: [PATCH v1] DOCS - logical replication, many little fixes
---
doc/src/sgml/logical-replication.sgml | 34 +++++++++++------------
doc/src/sgml/ref/alter_publication.sgml | 6 ++--
doc/src/sgml/ref/alter_subscription.sgml | 2 +-
doc/src/sgml/ref/create_publication.sgml | 6 ++--
doc/src/sgml/ref/create_subscription.sgml | 2 +-
5 files changed, 26 insertions(+), 24 deletions(-)
diff --git a/doc/src/sgml/logical-replication.sgml b/doc/src/sgml/logical-replication.sgml
index c06d255d2ed..98b74b195db 100644
--- a/doc/src/sgml/logical-replication.sgml
+++ b/doc/src/sgml/logical-replication.sgml
@@ -24,8 +24,8 @@
</para>
<para>
- When logical replication of a table typically starts, PostgreSQL takes
- a snapshot of the table's data on the publisher database and copies it
+ Logical replication of a table typically starts by PostgreSQL taking
+ a snapshot of the table's data on the publisher database and copying it
to the subscriber. Once complete, changes on the publisher since the
initial copy are sent continually to the subscriber. The subscriber
applies the data in the same
@@ -41,14 +41,14 @@
<listitem>
<para>
Sending incremental changes in a single database or a subset of a
- database to subscribers as they occur
+ database to subscribers as they occur.
</para>
</listitem>
<listitem>
<para>
Sending a subset of the database to multiple databases (i.e.,
- broadcast)
+ broadcast).
</para>
</listitem>
@@ -61,14 +61,14 @@
<listitem>
<para>
- Replicating between different major versions of PostgreSQL
+ Replicating between different major versions of PostgreSQL.
</para>
</listitem>
<listitem>
<para>
Replicating between PostgreSQL instances on different platforms (for
- example Linux to Windows)
+ example Linux to Windows).
</para>
</listitem>
@@ -90,7 +90,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.
@@ -211,8 +211,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>
@@ -988,7 +988,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>
@@ -1450,8 +1450,8 @@ Included in publications:
copied. However, if the subscriber is from a release prior to 15, then
all the columns in the table are copied during initial data synchronization,
ignoring any column lists. If the subscriber is from a release prior to 18,
- then initial table synchronization won't copy generated columns even if they
- are defined in the publisher.
+ then initial table synchronization will not copy generated columns even if
+ they are defined in the publisher.
</para>
<warning id="logical-replication-col-list-combining">
@@ -1748,7 +1748,7 @@ Included in publications:
<note>
<para>
If the subscriber is from a release prior to 18, then initial table
- synchronization won't copy generated columns even if they are defined in
+ synchronization will not copy generated columns even if they are defined in
the publisher.
</para>
</note>
@@ -2286,7 +2286,7 @@ CONTEXT: processing remote data for replication origin "pg_16395" during "INSER
and the next LSN of the finish LSN (i.e., 0/014C0379). The current position of
origins can be seen in the <link linkend="view-pg-replication-origin-status">
<structname>pg_replication_origin_status</structname></link> system view.
- Please note that skipping the whole transaction includes skipping changes that
+ Note that skipping the whole transaction includes skipping changes that
might not violate any constraint. This can easily make the subscriber
inconsistent.
The additional details regarding conflicting rows, such as their origin and
@@ -2294,7 +2294,7 @@ CONTEXT: processing remote data for replication origin "pg_16395" during "INSER
log. But note that this information is only available when
<link linkend="guc-track-commit-timestamp"><varname>track_commit_timestamp</varname></link>
is enabled on the subscriber. Users can use this information to decide
- whether to retain the local change or adopt the remote alteration. For
+ whether to retain the local change or adopt the remote change. For
instance, the <literal>DETAIL</literal> line in the above log indicates that
the existing row was modified locally. Users can manually perform a
remote-change-win.
@@ -2307,7 +2307,7 @@ CONTEXT: processing remote data for replication origin "pg_16395" during "INSER
may not be logged. In that case, it may be necessary to change the streaming
mode to <literal>on</literal> or <literal>off</literal> and cause the same
conflicts again so the finish LSN of the failed transaction will be written
- to the server log. For the usage of finish LSN, please refer to <link
+ to the server log. For the usage of finish LSN, refer to <link
linkend="sql-altersubscription"><command>ALTER SUBSCRIPTION ...
SKIP</command></link>.
</para>
@@ -2458,7 +2458,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_publication.sgml b/doc/src/sgml/ref/alter_publication.sgml
index aa32bb169e9..94259ed7c07 100644
--- a/doc/src/sgml/ref/alter_publication.sgml
+++ b/doc/src/sgml/ref/alter_publication.sgml
@@ -140,8 +140,10 @@ ALTER PUBLICATION <replaceable class="parameter">name</replaceable> RENAME TO <r
</para>
<para>
- Adding/Setting any schema when the publication also publishes a table with a
- column list, and vice versa is not supported.
+ Adding or setting a schema is not supported if the publication also
+ publishes any table from that schema with a column list. Likewise, adding
+ or setting a table with a column list is not supported if the publication
+ also publishes that table’s schema.
</para>
</refsect1>
diff --git a/doc/src/sgml/ref/alter_subscription.sgml b/doc/src/sgml/ref/alter_subscription.sgml
index f215fb0e5a2..e4f0b6b16c7 100644
--- a/doc/src/sgml/ref/alter_subscription.sgml
+++ b/doc/src/sgml/ref/alter_subscription.sgml
@@ -331,7 +331,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 0ac576d3f10..8d28c29d53e 100644
--- a/doc/src/sgml/ref/create_publication.sgml
+++ b/doc/src/sgml/ref/create_publication.sgml
@@ -157,7 +157,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
@@ -238,7 +238,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>.
@@ -278,7 +278,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 will not copy generated columns even if the parameter
<literal>publish_generated_columns</literal> is <literal>stored</literal>
in the publisher.
</para>
diff --git a/doc/src/sgml/ref/create_subscription.sgml b/doc/src/sgml/ref/create_subscription.sgml
index 07d5b1bd77c..58c69dc763d 100644
--- a/doc/src/sgml/ref/create_subscription.sgml
+++ b/doc/src/sgml/ref/create_subscription.sgml
@@ -691,7 +691,7 @@ CREATE SUBSCRIPTION <replaceable class="parameter">subscription_name</replaceabl
originated from further upstream. This scenario is detected and a WARNING is
logged to the user, but the warning is only an indication of a potential
problem; it is the user's responsibility to make the necessary checks to
- ensure the copied data origins are really as wanted or not.
+ ensure the copied data origins are acceptable.
</para>
<para>
--
2.47.3
view thread (3+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected]
Subject: Re: DOCS - typos and grammar issues across logical replication docs.
In-Reply-To: <CAHut+PuvY_wYLPJ4DTs7NE9Lu2ty4d-OgZAOJC-NvCM=2wwcQQ@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox