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

From Euler Taveira
Subject Re: Separate GUC for replication origins
Date
Msg-id 93c9b187-006f-46a5-b7aa-ed0f1d67a387@app.fastmail.com
Whole thread Raw
In response to Re: Separate GUC for replication origins  (vignesh C <vignesh21@gmail.com>)
Responses Re: Separate GUC for replication origins
Re: Separate GUC for replication origins
List pgsql-hackers
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'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.

I'm adding 2 patches. The 0001 contains the same version as the previous one
but I renamed the GUC name to max_active_replication_origins. I'm also
attaching 0002 if we decide that backward compatibility is not a concern so it
removes it and assign 10 as the default value. I'm adding an additional suffix
so CF bot doesn't grab 0002.


--
Euler Taveira

Attachment

pgsql-hackers by date:

Previous
From: Ryo Kanbayashi
Date:
Subject: Re: PGSERVICEFILE as part of a normal connection string
Next
From: Tom Lane
Date:
Subject: Dubious server log messages after pg_upgrade