Re: Issue with logical replication slot during switchover - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Issue with logical replication slot during switchover
Date
Msg-id CAA4eK1K6ziMep5L1XxfJp0Fpm2pbEyuk1zqqH4fPMwAuhC=m0w@mail.gmail.com
Whole thread Raw
In response to Re: Issue with logical replication slot during switchover  (Alexander Kukushkin <cyberdemn@gmail.com>)
List pgsql-hackers
On Wed, Nov 12, 2025 at 12:58 PM Alexander Kukushkin
<cyberdemn@gmail.com> wrote:
>
> On Wed, 12 Nov 2025 at 05:22, Amit Kapila <amit.kapila16@gmail.com> wrote:
>>
>> It is difficult to tell when this can happen but you detailed there is
>> a theoretical possibility of the same. If we had an in-core cluster
>> tool that manages nodes on its own which doesn't allow such scenarios
>> to happen then we could possibly say that using such a tool it is safe
>> to overwrite old primary's slots.
>
>
> That's a lot of ifs, and none of them could be fulfilled in the foreseeable future.
>
> Situation you describe is impossible.
> When there is a split-brain and someone drops and re-creating logical slots with the same names on the old primary -
suchnode can't be joined as a standby without pg_rewind. 
> In its current state pg_rewind wipes the pg_replslot directory, and therefore there will be no replication slots.
>

Say, the only operations that happened are slot-drop-recreate and or
some operations on unlogged tables. Why then pg_rewind is required?

--
With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: Akshay Joshi
Date:
Subject: Re: [PATCH] Add pg_get_database_ddl() function to reconstruct CREATE DATABASE statement
Next
From: Alexander Kukushkin
Date:
Subject: Re: Issue with logical replication slot during switchover