Re: failover logical replication slots

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Fabrice Chapuis <fabrice636861(at)gmail(dot)com>
Cc: "Zhijie Hou (Fujitsu)" <houzj(dot)fnst(at)fujitsu(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: failover logical replication slots
Date: 2025-06-12 10:05:56
Message-ID: CAA4eK1+M4-_4GY-ZmjM8cB2-kAE6a8yfdJ0prh1AnB2MFQb7Lg@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Jun 12, 2025 at 3:07 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
> On Thu, Jun 12, 2025 at 2:32 PM Fabrice Chapuis <fabrice636861(at)gmail(dot)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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Fabrice Chapuis 2025-06-12 10:23:24 Re: failover logical replication slots
Previous Message Amit Kapila 2025-06-12 09:37:28 Re: failover logical replication slots