Attached is a patch with what I hope we can agree on. On Wed, 2026-10-07 at 17:03 +0100, Thom Brown wrote: > On Wed, 7 Oct 2026 at 15:32, Laurenz Albe <[email protected]> wrote: > > On Wed, 2026-10-07 at 11:58 +0100, Thom Brown wrote: > > > > > > > > --- a/doc/src/sgml/ref/create_subscription.sgml > > > +++ b/doc/src/sgml/ref/create_subscription.sgml > > > > > <para> > > > Since no connection is made when this option is > > > - <literal>false</literal>, no tables and sequences are > > > subscribed. To > > > + <literal>false</literal>, no tables or sequences are > > > subscribed. To > > > > Hm. I think "and" would be the better conjunction here (although "or" > > is not really wrong). > > I think an "or" after a "no" doesn't read well. I think, in order to > use "and", it would have to read "tables and sequences are not > subscribed."
I went with "tables and sequences are not yet subscribed". > > > > > - overall system performance. This option provides minimal > > > performance > > > + overall system performance. This option incurs minimal > > > performance > > > overhead when applied appropriately. The following scenarios > > > illustrate > > > > I see your point, although you could argue that "minimal performance > > overhead" > > is a feature, and you provide a feature rather than incur it. > > How about "provides reduced performance overhead"? > > I'm not keen on "providing" any overhead, but we could just be > completely neutral about it: > > "This option has minimal performance overhead when applied appropriately." I read the paragraph again, and I think that your original "incurs" is actually better. After all, "retain_dead_tuples" incurs an overhead. It's just that that overhead can be small if you do it right. > > > c. Read-Only Subscribers: > > > In configurations involving single or multiple publisher nodes > > > performing concurrent write operations, read-only subscriber > > > nodes may > > > - replicate changes without seeing a performance impact if it > > > does index > > > - scan. However, if the subscriber is impacted due to > > > replication lag or > > > - scan performance (say due to sequential scans), it needs to > > > follow one > > > + replicate changes without performance degradation if > > > performing index > > > + scans. However, if the subscriber is affected due to > > > replication lag or > > > + scan performance (e.g. due to sequential scans), it needs to > > > follow one > > > of the two previous strategies to distribute the workload on > > > the > > > subscriber. > > > > Your change clearly is an improvement (the original was grammatically > > wrong). > > But "subscriber nodes may replicate changes without performance degradation > > if performing index scans" still feels less than perfect. Shouldn't it be > > "when performing index scans" or "when they perform index scans" or - even > > better - "during index scans"? > > Yeah, fair enough. I would avoid "during index scans" as it makes it > about timing. But "when performing index scans" sounds right. Done that way. > > > See <xref linkend="logical-replication-security"/> for details on > > > how to configure access control between the subscription and the > > > - publication instance. > > > + publisher instance. > > > > I think you should be consistent: "between the subscriber and the publisher > > instance". But perhaps it would be best to retain the original, because > > "publication" and "subscription" are the names of the PostgreSQL objects > > involved. How about "between the database with the subscription and the > > database with the publication"? > > Yeah, point taken. Maybe leave that as it is. Done. I have also removed the two "the" from the system administration function documentation, as Masahiko suggested. Masahiko, do you want to commit that before v19 goes live, or should we add it to the next commitfest? Yours, Laurenz Albe
From 2d60772c92b120a5f24c0967ff117ab50061c1e5 Mon Sep 17 00:00:00 2001 From: Laurenz Albe <[email protected]> Date: Sun, 18 Oct 2026 20:31:32 +0200 Subject: [PATCH v2] Small fixes for the CREATE SUBSCRIPTION documentation The documentation added by commits 55cefadde8, 228c370868, a850be2fe6 and 8756930190 had grammatical and stylistic shortcomings. In passing, remove two articles from the system administration functions documentation. Author: Thom Brown <[email protected]> Reviewed-By: Laurenz Albe <[email protected]> Reviewed-By: Masahiko Sawada <[email protected]> Discussion: https://postgr.es/m/CAA-aLv4tAU6yY=oua7fisy+kk_4bs-mjrequjju-hhjoa9t...@mail.gmail.com --- doc/src/sgml/func/func-admin.sgml | 4 ++-- doc/src/sgml/ref/create_subscription.sgml | 25 ++++++++++++----------- 2 files changed, 15 insertions(+), 14 deletions(-) diff --git a/doc/src/sgml/func/func-admin.sgml b/doc/src/sgml/func/func-admin.sgml index 64b0e7bb972..800c1564e7b 100644 --- a/doc/src/sgml/func/func-admin.sgml +++ b/doc/src/sgml/func/func-admin.sgml @@ -1118,7 +1118,7 @@ postgres=# SELECT '0/0'::pg_lsn + pd.segment_number * ps.setting::int + :offset Copies an existing physical replication slot named <parameter>src_slot_name</parameter> to a physical replication slot named <parameter>dst_slot_name</parameter>. The new slot name cannot be <literal>pg_conflict_detection</literal>, - as it is reserved for the conflict detection. + as it is reserved for conflict detection. The copied physical slot starts to reserve WAL from the same <acronym>LSN</acronym> as the source slot. <parameter>temporary</parameter> is optional. If <parameter>temporary</parameter> @@ -1143,7 +1143,7 @@ postgres=# SELECT '0/0'::pg_lsn + pd.segment_number * ps.setting::int + :offset slot named <parameter>dst_slot_name</parameter>, optionally changing the output plugin and persistence. The new slot name cannot be <literal>pg_conflict_detection</literal> as it is reserved for - the conflict detection. The copied logical slot starts from the same + conflict detection. The copied logical slot starts from the same <acronym>LSN</acronym> as the source logical slot. Both <parameter>temporary</parameter> and <parameter>plugin</parameter> are optional; if they are omitted, the values of the source slot are used. diff --git a/doc/src/sgml/ref/create_subscription.sgml b/doc/src/sgml/ref/create_subscription.sgml index 6248c228a64..0d27d03603b 100644 --- a/doc/src/sgml/ref/create_subscription.sgml +++ b/doc/src/sgml/ref/create_subscription.sgml @@ -141,9 +141,9 @@ CREATE SUBSCRIPTION <replaceable class="parameter">subscription_name</replaceabl <para> Since no connection is made when this option is - <literal>false</literal>, no tables and sequences are subscribed. To - initiate replication, you must manually create the replication slot, - enable the failover if required, enable the subscription, and refresh + <literal>false</literal>, tables and sequences are not yet subscribed. + To initiate replication, you must manually create the replication slot, + enable failover if required, enable the subscription, and refresh the subscription. See <xref linkend="logical-replication-subscription-examples-deferred-slot"/> for examples. @@ -184,7 +184,7 @@ CREATE SUBSCRIPTION <replaceable class="parameter">subscription_name</replaceabl <para> Name of the publisher's replication slot to use. The default is to use the name of the subscription for the slot name. The name cannot - be <literal>pg_conflict_detection</literal> as it is reserved for the + be <literal>pg_conflict_detection</literal> as it is reserved for conflict detection. </para> @@ -555,7 +555,7 @@ CREATE SUBSCRIPTION <replaceable class="parameter">subscription_name</replaceabl Additionally when enabling <literal>retain_dead_tuples</literal> for conflict detection in logical replication, it is important to design the replication topology to balance data retention requirements with - overall system performance. This option provides minimal performance + overall system performance. This option incurs minimal performance overhead when applied appropriately. The following scenarios illustrate effective usage patterns when enabling this option. </para> @@ -581,9 +581,9 @@ CREATE SUBSCRIPTION <replaceable class="parameter">subscription_name</replaceabl c. Read-Only Subscribers: In configurations involving single or multiple publisher nodes performing concurrent write operations, read-only subscriber nodes may - replicate changes without seeing a performance impact if it does index - scan. However, if the subscriber is impacted due to replication lag or - scan performance (say due to sequential scans), it needs to follow one + replicate changes without performance degradation when performing index + scans. However, if the subscriber is affected due to replication lag or + scan performance (e.g. due to sequential scans), it needs to follow one of the two previous strategies to distribute the workload on the subscriber. </para> @@ -636,9 +636,10 @@ CREATE SUBSCRIPTION <replaceable class="parameter">subscription_name</replaceabl can be manually resumed by re-enabling <literal>retain_dead_tuples</literal>. </para> <para> - Note that overall retention will not stop if other subscriptions that - have a value greater than 0 for this parameter have not exceeded it, - or if they set this option to 0. + Note that overall retention will not stop while any other subscription + with <literal>retain_dead_tuples</literal> enabled either has this + option set to <literal>0</literal> or has not yet exceeded its nonzero + limit. </para> <para> This option is effective only when @@ -769,7 +770,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 origins of the copied data are as intended. </para> <para> -- 2.56.0
