Re: Separate GUC for replication origins - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: Separate GUC for replication origins
Date
Msg-id a040a1a5-c1a2-4988-ad92-a610ffbf4520@eisentraut.org
Whole thread Raw
List 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.




pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [PROPOSAL] : Disallow use of empty column name in (column_name '') in ALTER or CREATE of foreign table.
Next
From: "Euler Taveira"
Date:
Subject: Re: log_min_messages per backend type