Re: Issue with logical replication slot during switchover

On Tue, Nov 18, 2025 at 10:27 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
> On Wed, Nov 19, 2025 at 6:26 AM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
> >
> > On Tue, Nov 18, 2025 at 1:30 AM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> > >
> > > On Sat, Nov 15, 2025 at 4:02 AM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
> > > >
> > > > On Fri, Nov 14, 2025 at 2:39 AM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> > > > >
> > > > >
> > > > > The point is quite fundamental, do you think we can sync to a
> > > > > pre-existing slot with the same name and failover marked as true after
> > > > > the first time the node joins a new primary?
> > > >
> > > > Given the current behavior that we cannot create a logical slot with
> > > > failover=true on the standby, it makes sense to me that we overwrite
> > > > the pre-existing slot (with synced=false and failover=true) on the old
> > > > primary by the slot (with synced=true and failover=true) on the new
> > > > primary if their names, plugin and other properties matches and the
> > > > pre-existing slot has lesser LSNs and XIDs than the one on the new
> > > > primary. But at the same time, we need to consider the possible future
> > > > changes that allow users to create a slot with failover=true also on
> > > > the standby.
> > > >
> > > > Alexander pointed out[1] that allowing to create a slot with
> > > > failover=true on the standby won't work with the current
> > > > implementation. I agree with his analysis, and I guess we would need
> > > > more changes than simply allowing it, regardless of accepting the
> > > > proposed change. We might need to introduce a replication slot origin
> > > > or a generation.
> > > >
> > >
> > > AFAICS, the email you pointed out wrote about use cases, not the
> > > actual code implementation. We can discuss use cases if we want to
> > > pursue that implementation, but the reason why we decided not to allow
> > > it was for the cases where users try to configure cascaded standbys to
> > > also try to sync slots from the first standby that are already being
> > > synced from the primary. There are quite a few technical challenges in
> > > supporting that, like how to make sure primary waits even for cascaded
> > > standbys before sending the changes to logical subscribers.
> >
> > Right. My point is that these are two independent issues. The fact
> > that creating a slot with failover=true directly on a standby is
> > difficult (due to the cascaded-standby cases you mentioned) does not,
> > by itself, justify allowing us to overwrite an existing slot with
> > failover=true and synced=false during slot synchronization.
> >
> > > OTOH, for the cases where there is a totally different logical slot on
> > > standby (not present on primary) with failover=true, we can allow it
> > > to be synced from standby-1 to a cascaded standby, though we need some
> > > way to distinguish those cases. For example, during sync on cascaded
> > > standby, we can ensure that the slot being synced is not a sync-slot
> > > (failover=true and sync=true).
> >
> > Yes. We need some way to distinguish those slots, otherwise if users
> > create a slot with the same name on the primary, the slot on standby-1
> > (a cascading standby) could be overwritten. I think we would need some
> > additional metadata per slot to support that safely.
> >
>
> It shouldn't be overwritten as of current HEAD because we give ERROR
> if such a slot exists on standby but if we allow overwriting it as
> being discussed here then we would require additional metadata per
> slot to distinguish this case.

I think we need to clarify that suppose the standby has a slot with
failover=true and synced=false and the primary has the slot with the
same name, failover=true, and synced=true, what problem could occur if
we allow overwriting the slot on the standby by the one on the
primary. I see there are some cases where the old primary needs to
delete pre-existing slots before joining the new primary, but should
we make such operation mandatory in switchover cases? It might be
worth considering whether such additional metadata per slot is
required before allowing overwriting the slot.

Regards,

--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com