Re: Issue with logical replication slot during switchover
| От | Amit Kapila |
|---|---|
| Тема | Re: Issue with logical replication slot during switchover |
| Дата | |
| Msg-id | CAA4eK1LhogAeNQE5yy04oK+Lx_tXGRkjmcmpcQT2c-d6Yj1gRg@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Issue with logical replication slot during switchover (Fabrice Chapuis <fabrice636861@gmail.com>) |
| Ответы |
Re: Issue with logical replication slot during switchover
|
| Список | pgsql-hackers |
On Tue, Nov 11, 2025 at 9:27 PM Fabrice Chapuis <fabrice636861@gmail.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 aimis 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.
В списке pgsql-hackers по дате отправления: