Re: Separate GUC for replication origins

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
EDB https://www.enterprisedb.com/