Re: Separate GUC for replication origins

From: Peter Eisentraut <peter(at)eisentraut(dot)org>
To: Euler Taveira <euler(at)eulerto(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Separate GUC for replication origins
Date: 2024-12-19 13:31:48
Message-ID: a040a1a5-c1a2-4988-ad92-a610ffbf4520@eisentraut.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Euler Taveira 2024-12-19 13:34:39 Re: log_min_messages per backend type
Previous Message Robert Haas 2024-12-19 13:29:56 Re: [PROPOSAL] : Disallow use of empty column name in (column_name '') in ALTER or CREATE of foreign table.