Re: Separate GUC for replication origins
vignesh C <vignesh21@gmail.com>
From: vignesh C <vignesh21@gmail.com>
To: Euler Taveira <euler@eulerto.com>
Cc: Peter Eisentraut <peter@eisentraut.org>,
Amit Kapila <amit.kapila16@gmail.com>, Masahiko Sawada <sawada.mshk@gmail.com>, pgsql-hackers@lists.postgresql.org
Date: 2025-03-13T02:06:41Z
Lists: 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
Commits
-
Add GUC option to control maximum active replication origins.
- 04ff636cbce4 18.0 landed
-
Better document logical replication parameters
- a8500750ca0a 16.0 cited
-
Introduce replication progress tracking infrastructure.
- 5aa2350426c4 9.5.0 cited