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.
