Re: failover logical replication slots - Mailing list pgsql-hackers

From Fabrice Chapuis
Subject Re: failover logical replication slots
Date
Msg-id CAA5-nLC4+fuf80hfJTBiLNe9hp2fs8p8-F5FQjwZ+2L5GDL5hg@mail.gmail.com
Whole thread Raw
In response to Re: failover logical replication slots  (Amit Kapila <amit.kapila16@gmail.com>)
List 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 by date:

Previous
From: Amit Kapila
Date:
Subject: Re: failover logical replication slots
Next
From: shveta malik
Date:
Subject: Re: Conflict detection for update_deleted in logical replication