Re: Separate GUC for replication origins

On Fri, Mar 14, 2025, at 5:48 AM, vignesh C wrote:
> 1) Should we add a test case to verify that if
> max_active_replication_origins is set to -1, it will use
> max_replication_slots value:

I don't think so. I added the following assert to test exactly this condition.

if (max_active_replication_origins == -1) /* failed to apply it? */
SetConfigOption("max_active_replication_origins", buf,
PGC_POSTMASTER, PGC_S_OVERRIDE);
}
Assert(max_active_replication_origins != -1);

> 2) Should we consider about the origin's created by user using the
> replication managment function at [1] or is it intentionally left out:
> - <link linkend="guc-max-replication-slots-subscriber"><varname>max_replication_slots</varname></link>
> + <link linkend="guc-max-active-replication-origins"><varname>max_active_replication_origins</varname></link>
> must be set to at least the number of subscriptions that will be added to
> the subscriber, plus some reserve for table synchronization.

I kept a minimal patch. The current sentence is vague because (a) it doesn't
refer to replication solutions that don't create subscription (as you said) and
(b) it doesn't specify the maximum number of replication origins that are
simultaneously used for table synchronization.

We can certainly expand the replication origin documentation but I don't think
it is material for this patch. I also don't think it is appropriate to expose
implementation details about table synchronization in a end user page. If we
can explain it without saying too much about the implementation details, fine.

--
Euler Taveira
EDB https://www.enterprisedb.com/