Re: PGDOCS - Logical replication GUCs - added some xrefs - Mailing list pgsql-hackers

From vignesh C
Subject Re: PGDOCS - Logical replication GUCs - added some xrefs
Date
Msg-id CALDaNm32HN70mGSVjoTXfBuv4+iff1EGnDa=j21Ohxzyaj4aPA@mail.gmail.com
Whole thread Raw
In response to Re: PGDOCS - Logical replication GUCs - added some xrefs  (Peter Smith <smithpb2250@gmail.com>)
Responses Re: PGDOCS - Logical replication GUCs - added some xrefs
List pgsql-hackers
On Tue, 15 Nov 2022 at 11:17, Peter Smith <smithpb2250@gmail.com> wrote:
>
> On Sun, Nov 13, 2022 at 11:47 AM vignesh C <vignesh21@gmail.com> wrote:
> >
> > On Mon, 24 Oct 2022 at 13:15, Peter Smith <smithpb2250@gmail.com> wrote:
> > >
> > > Hi hackers.
> > >
> > > There is a docs Logical Replication section "31.10 Configuration
> > > Settings" [1] which describes some logical replication GUCs, and
> > > details on how they interact with each other and how to take that into
> > > account when setting their values.
> > >
> > > There is another docs Server Configuration section "20.6 Replication"
> > > [2] which lists the replication-related GUC parameters, and what they
> > > are for.
> > >
> > > Currently AFAIK those two pages are unconnected, but I felt it might
> > > be helpful if some of the parameters in the list [2] had xref links to
> > > the additional logical replication configuration information [1]. PSA
> > > a patch to do that.
> > >
> > > ~~
> > >
> > > Meanwhile, I also suspect that the main blurb top of [1] is not
> > > entirely correct... it says "These settings control the behaviour of
> > > the built-in streaming replication feature", although some of the GUCs
> > > mentioned later in this section are clearly for "logical replication".
> >
> > The introduction mainly talks about streaming replication and the page
> > [1] subsection "Subscribers" clearly mentions that these
> > configurations are for logical replication. As we already have a
> > separate page [2] to detail about logical replication configurations,
> > it might be better to move the "subscribers" section from [1] to [2].
> >
> > [1] 20.6 Replication -
> > https://www.postgresql.org/docs/current/runtime-config-replication.html
> > [2] 31.10 Configuration Settings -
> > https://www.postgresql.org/docs/current/logical-replication-config.html
> >
>
> Thanks, Vignesh. Your suggestion (to move that "Subscribers" section)
> seemed like a good idea to me, so PSA my patch v2 to implement that.
>
> Now, on the Streaming Replication page
> - the blurb has a reference to information about logical replication config
> - the "Subscribers" section was relocated to the other page
>
> Now, on the Logical Replication "Configuration Settings" page
> - there are new subsections for "Publishers", "Subscribers" (copied), "Notes"
> - some wording is rearranged but the content is basically the same as before

One suggestion:
The format of subscribers includes the data type and default values,
the format of publishers does not include data type and default
values. We can try to maintain the consistency for both publisher and
subscriber configurations.
+   <para>
+    <varname>wal_level</varname> must be set to <literal>logical</literal>.
+   </para>

+     <term><varname>max_logical_replication_workers</varname>
(<type>integer</type>)
+     <indexterm>
+      <primary><varname>max_logical_replication_workers</varname>
configuration parameter</primary>
+     </indexterm>
+     </term>
+     <listitem>
+      <para>
+       Specifies maximum number of logical replication workers. This
must be set
+       to at least the number of subscriptions (for apply workers), plus some
+       reserve for the table synchronization workers.
+      </para>
+      <para>

If we don't want to keep the same format, we could give a link to
runtime-config-replication where data type and default is defined for
publisher configurations max_replication_slots and max_wal_senders.

Regards,
Vignesh



pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: Add palloc_aligned() to allow arbitrary power of 2 memory alignment
Next
From: Ranier Vilela
Date:
Subject: Re: Avoid overhead open-close indexes (catalog updates)