Re: Separate GUC for replication origins

From: "Euler Taveira" <euler(at)eulerto(dot)com>
To: "vignesh C" <vignesh21(at)gmail(dot)com>
Cc: "Peter Eisentraut" <peter(at)eisentraut(dot)org>, "Amit Kapila" <amit(dot)kapila16(at)gmail(dot)com>, "Masahiko Sawada" <sawada(dot)mshk(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Separate GUC for replication origins
Date: 2025-03-17 23:43:28
Message-ID: 6123b808-85e2-4910-8cc4-a6a72b21b9a8@app.fastmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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/

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiko Sawada 2025-03-17 23:44:26 Re: Separate GUC for replication origins
Previous Message Jacob Champion 2025-03-17 23:34:45 Re: ecdh support causes unnecessary roundtrips