Re: Separate GUC for replication origins

From: "Euler Taveira" <euler(at)eulerto(dot)com>
To: "Peter Eisentraut" <peter(at)eisentraut(dot)org>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Separate GUC for replication origins
Date: 2025-01-08 15:38:58
Message-ID: 7ccb750a-0169-4965-9bd7-c5a2ef68fbc7@app.fastmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Dec 19, 2024, at 10:31 AM, Peter Eisentraut wrote:
> On 10.12.24 19:41, Euler Taveira wrote:
> > I'm attaching a patch that adds max_replication_origins. It basically
> > replaces
> > all of the points that refers to max_replication_slots on the subscriber. It
> > uses the same default value as max_replication_slots (10). I did nothing to
> > keep the backward compatibility. I mean has a special value (like -1) that
> > means same value as max_replication_slots. Is it worth it? (If not, it
> > should
> > be mentioned in the commit message.)
>
> I think some backward compatibility tweak like that would be useful.
> Otherwise, the net effect of this is that most people will have to do
> one more thing than before to keep their systems working. Also, all
> deployment and automation scripts would have to be updated for this.
>
This new patch includes the special value (-1) that uses max_replication_slots
instead.

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

Attachment Content-Type Size
v2-0001-Separate-GUC-for-replication-origins.patch text/x-patch 24.8 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2025-01-08 15:42:09 Re: ecpg command does not warn COPY ... FROM STDIN;
Previous Message Tom Lane 2025-01-08 15:29:12 Re: Fix a wrong errmsg in AlterRole()