Re: Separate GUC for replication origins
| От | Euler Taveira |
|---|---|
| Тема | Re: Separate GUC for replication origins |
| Дата | |
| Msg-id | 6123b808-85e2-4910-8cc4-a6a72b21b9a8@app.fastmail.com обсуждение исходный текст |
| Ответ на | Re: Separate GUC for replication origins (vignesh C <vignesh21@gmail.com>) |
| Список | pgsql-hackers |
On Fri, Mar 14, 2025, at 5:48 AM, vignesh C wrote:
1) Should we add a test case to verify that ifmax_active_replication_origins is set to -1, it will usemax_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 thereplication 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 tothe 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.
В списке pgsql-hackers по дате отправления: