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.
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. |