Date: Mon, 7 Feb 2022 12:32:22 -0800
From: Andres Freund <andres@anarazel.de>
To: Ashutosh Sharma <ashu.coek88@gmail.com>
Cc: Peter Eisentraut <peter.eisentraut@enterprisedb.com>,
	pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: Synchronizing slots from primary to standby
Message-ID: <20220207203222.22aktwxrt3fcllru@alap3.anarazel.de>
References: <514f6f2f-6833-4539-39f1-96cd1e011f23@enterprisedb.com>
 <18dbc929-a281-8552-4f1d-7e4d0e4eedba@enterprisedb.com>
 <646acd8d-9896-ed8d-2ab4-0bf11b3285d4@enterprisedb.com>
 <20220205195944.drwc3psrb5udt2cw@alap3.anarazel.de>
 <CAE9k0PnGmQ97ikLy2oBDoom72FsV_x+H9JuptJ4ysx=CFM-+kQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAE9k0PnGmQ97ikLy2oBDoom72FsV_x+H9JuptJ4ysx=CFM-+kQ@mail.gmail.com>
Archived-At: <https://www.postgresql.org/message-id/20220207203222.22aktwxrt3fcllru%40alap3.anarazel.de>
Precedence: bulk

Hi,

On 2022-02-07 13:38:38 +0530, Ashutosh Sharma wrote:
> Are you talking about this scenario - what if the logical replication
> slot on the publisher is dropped, but is being referenced by the
> standby where the slot is synchronized?

It's a bit hard to say, because neither in this thread nor in the patch I've
found a clear description of what the syncing needs to & tries to
guarantee. It might be that that was discussed in one of the precursor
threads, but...

Generally I don't think we can permit scenarios where a slot can be in a
"corrupt" state, i.e. missing required catalog entries, after "normal"
administrative commands (i.e. not mucking around in catalog entries / on-disk
files). Even if the sequence of commands may be a bit weird. All such cases
need to be either prevented or detected.


As far as I can tell, the way this patch keeps slots on physical replicas
"valid" is solely by reorderbuffer.c blocking during replay via
wait_for_standby_confirmation().

Which means that if e.g. the standby_slot_names GUC differs from
synchronize_slot_names on the physical replica, the slots synchronized on the
physical replica are not going to be valid.  Or if the primary drops its
logical slots.


> Should the redo function for the drop replication slot have the capability
> to drop it on standby and its subscribers (if any) as well?

Slots are not WAL logged (and shouldn't be).

I think you pretty much need the recovery conflict handling infrastructure I
referenced upthread, which recognized during replay if a record has a conflict
with a slot on a standby.  And then ontop of that you can build something like
this patch.

Greetings,

Andres Freund