Re: failover logical replication slots
От | Fabrice Chapuis |
---|---|
Тема | Re: failover logical replication slots |
Дата | |
Msg-id | CAA5-nLC4+fuf80hfJTBiLNe9hp2fs8p8-F5FQjwZ+2L5GDL5hg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: failover logical replication slots (Amit Kapila <amit.kapila16@gmail.com>) |
Список | pgsql-hackers |
The parameter sync_replication_slots could be tested if it is set to true before doing any action on failover slots.
Regards,
Fabrice
On Thu, Jun 12, 2025 at 12:06 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
On Thu, Jun 12, 2025 at 3:07 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> On Thu, Jun 12, 2025 at 2:32 PM Fabrice Chapuis <fabrice636861@gmail.com> wrote:
> >
>
> > After the first failover, the following failovers will work given that the sync flag is true on both the primary and standby slots.
> >
> > After new sandby is attached to the primary, can we imagine that when the sync worker process is started we check if a failover slot exists on the standby, if so we drop it before recreating a new one for syncing?
> >
>
> This has the risk of dropping an unwarranted slot.
>
On thinking further, even if we decide to support this functionality
of overwriting the existing slots in some way, what is guarantee that
the new standby will enable syncslot functionality (via
sync_replication_slots)? If standby doesn't enable the
sync_replication_slots then such slots will remain dangling and lead
to the accumulation of WAL. So, I think the first thing to do is to
avoid such cases, both for failover and non-failover slots. Then we
should consider ways to allow overwriting existing slots on standby in
the scenario you explained.
--
With Regards,
Amit Kapila.
В списке pgsql-hackers по дате отправления: