Re: Issue with logical replication slot during switchover

On Tue, Nov 11, 2025 at 9:27 PM Fabrice Chapuis <fabrice636861(at)gmail(dot)com> wrote:
>
> if I resume your scenario
> 1. A standby S has a failover slot slot1 synchronized with slot1 on primary P
> 2. We promote S
> 3. On P we drop slot1 and create slot1 again with failover mode (a subscriber exist on another instance by example)
> 4. A rewind is performed on P the former primary to rejoin S the former standby
> 5. On P slot1 is automatically dropped and recreated to be synchronized
>
> In which context this kind of scenario could happend?
>

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.

> Isn't the goal to find a solution for a switchover which is carried out for maintenance on a Postgres cluster, the aim is to find a compromise to cover the most likely scenarios.
>

Yes, that is why I thought of providing some form of UI that can allow
outside cluster solutions to manage such slots.

> Do you think we must come back to the allow_overwrite flag approach or another solution?
>

We can wait for a few days to see what others think on this matter.

--
With Regards,
Amit Kapila.