Re: Synchronizing slots from primary to standby - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: Synchronizing slots from primary to standby
Date
Msg-id 2d67fe58-b3b5-ab9e-e417-23752733cdb6@enterprisedb.com
Whole thread Raw
In response to Re: Synchronizing slots from primary to standby  (Andres Freund <andres@anarazel.de>)
Responses Re: Synchronizing slots from primary to standby  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On 05.02.22 20:59, Andres Freund wrote:
> On 2022-01-03 14:46:52 +0100, Peter Eisentraut wrote:
>>  From ec00dc6ab8bafefc00e9b1c78ac9348b643b8a87 Mon Sep 17 00:00:00 2001
>> From: Peter Eisentraut<peter@eisentraut.org>
>> Date: Mon, 3 Jan 2022 14:43:36 +0100
>> Subject: [PATCH v3] Synchronize logical replication slots from primary to
>>   standby
> I've just skimmed the patch and the related threads. As far as I can tell this
> cannot be safely used without the conflict handling in [1], is that correct?

This or similar questions have been asked a few times about this or 
similar patches, but they always come with some doubt.  If we think so, 
it would be useful perhaps if we could come up with test cases that 
would demonstrate why that other patch/feature is necessary.  (I'm not 
questioning it personally, I'm just throwing out ideas here.)



pgsql-hackers by date:

Previous
From: Yura Sokolov
Date:
Subject: Re: Accommodate startup process in a separate ProcState array slot instead of in MaxBackends slots.
Next
From: Tom Lane
Date:
Subject: Re: pgsql: Add TAP test to automate the equivalent of check_guc