Re: Issue with logical replication slot during switchover
| От | Amit Kapila |
|---|---|
| Тема | Re: Issue with logical replication slot during switchover |
| Дата | |
| Msg-id | CAA4eK1K6ziMep5L1XxfJp0Fpm2pbEyuk1zqqH4fPMwAuhC=m0w@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Issue with logical replication slot during switchover (Alexander Kukushkin <cyberdemn@gmail.com>) |
| Список | 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 по дате отправления: