Re: Separate GUC for replication origins - Mailing list pgsql-hackers

From vignesh C
Subject Re: Separate GUC for replication origins
Date
Msg-id CALDaNm08gN2U9x2rU1askMN0rvDQNECftNQXzugcwh00SyS9=w@mail.gmail.com
Whole thread Raw
In response to Re: Separate GUC for replication origins  ("Euler Taveira" <euler@eulerto.com>)
List pgsql-hackers
On Thu, 13 Mar 2025 at 05:59, Euler Taveira <euler@eulerto.com> wrote:
>
> On Wed, Mar 12, 2025, at 8:47 AM, vignesh C wrote:
>
> I reviewed the discussion on this thread and believe we now have an
> agreement on the design and GUC names. However, the patch still needs
> updates and extensive testing, especially considering its impact on
> backward compatibility. I'm unsure if this feature can be committed in
> the current CommitFest. If you're okay with it, we can move it to the
> next CommitFest. However, if you prefer to keep it, we can do our best
> to complete it and make a final decision at the end of the CommitFest.
>
>
> This is a mechanical patch. I was waiting if someone would object or suggest a
> better GUC name. It seems to me it isn't. The pre existing GUC
> (max_replication_slots) already has coverage. I don't know what additional
> tests you have in mind. Could you elaborate?

I was considering any potential impact on pg_upgrade and
pg_createsubscriber. I will run tests with the latest posted patch to
verify.

> I'm biased to say that it is one of the easiest patches to commit because it is
> just assigning a new GUC name for a pre existing functionality. If there is no
> interested in it, it will be moved to the next CF.

Sounds like a plan! Let's verify it and work towards getting it committed.

Regards,
Vignesh



pgsql-hackers by date:

Previous
From: Nathan Bossart
Date:
Subject: Re: Dubious server log messages after pg_upgrade
Next
From: Peter Smith
Date:
Subject: Re: DOCS: Make the Server Application docs synopses more consistent