Re: [PATCH] Note effect of max_replication_slots on subscriber side in documentation.

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Paul Martinez <paulmtz(at)google(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] Note effect of max_replication_slots on subscriber side in documentation.
Date: 2021-02-27 09:05:37
Message-ID: CAA4eK1JhYmP+HM-LUFJmmL0Qh+L-uB78GMLdJ3J3MU9EdOaJOQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Feb 27, 2021 at 2:47 AM Paul Martinez <paulmtz(at)google(dot)com> wrote:
>
> On Fri, Feb 26, 2021 at 5:22 AM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> >
> > https://www.postgresql.org/docs/devel/logical-replication-config.html
> >
>
> Ah, yep. I added a clause to the end of the sentence to clarify why we're
> using max_replication_slots here:
>
> - The subscriber also requires the max_replication_slots to be set.
>
> + The subscriber also requires that max_replication_slots be set to
> + configure how many replication origins can be tracked.
>

LGTM.

> >
> > Okay, that makes sense. However, I have sent a patch today (see [1])
> > where I have slightly updated the subscriber-side configuration
> > paragraph. From PG-14 onwards, table synchronization workers also use
> > origins on subscribers, so you might want to adjust.
> >
> > ...
> >
> > I guess we can leave adding GUC to some other day as that might
> > require a bit broader acceptance and we are already near to the start
> > of last CF. I think we can still consider it if we few more people
> > share the same opinion as yours.
> >
>
> Great. I'll wait to update the GUC patch until your patch and/or my
> doc-only patch get merged. Should I add it to the March CF?
>

Which patch are you asking about doc-patch or GUC one? If you are
asking for a doc-patch, then I don't think it is required, I'll take
care of this sometime next week. For the GUC patch, my suggestion
would be to propose for v15 with an appropriate use-case. At this
point (just before the last CF of release), people are mostly busy
with patches that are going on for a long time so this might not get
due attention unless few people show-up and say it is important.
However, it is up to you, if you want feel free to register your GUC
patch in the upcoming CF.

> Separate question: are documentation updates like these ever backported
> to older versions that are still supported?
>

Not every doc-change is back-ported but I think it is good to backport
the user-visible ones. It is on a case-by-case basis. For this, I
think we can backport unless you or others feel otherwise?

> And if so, would the changes
> be reflected immediately, or would they require a minor point release?
>

Where you are referring to the docs? If you are checking from code, it
will be reflected immediately.

--
With Regards,
Amit Kapila.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dilip Kumar 2021-02-27 09:14:54 Re: [HACKERS] Custom compression methods
Previous Message Thomas Munro 2021-02-27 08:30:09 Re: Remove latch.c workaround for Linux < 2.6.27