Re: Fixes for create subscription page

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 <laurenz(dot)albe(at)cybertec(dot)at> 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