Re: Issue with logical replication slot during switchover

> 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...
I'm not sure to understand the semantics related to the `synced` flag but
why `synced` flag can be true on a primary instance? AFAICS if
`synced=true` then it means taht the slot is inactive and it is
synchronized with a slot on a remote instance. On a primary, what is the
meaning of having the flag synced set to true?
There's already an open thread dealing with this issue [1].
The problem I see is being able to distinguish between 2 situations:
1) A failover slot has been created on a standby (failover=true and
synced=false) in a context of cascading standby. In this case the slot must
not be deleted.
2) A former primary has a slot (failover=true and synced=false) that must
be resynchronized and that can be overwritten.
Why not to use a slot's metadata (allow_overwrite) to treat these two
situations separately.

Regards,

Fabrice

[1]:
PostgreSQL: Clear logical slot's 'synced' flag on promotion of standby
<https://www.postgresql.org/message-id/flat/CAJpy0uBJqTQdq+UDW55oK2bhxMig=FaEYFV=+ZaKmtmgNWwsHw(at)mail(dot)gmail(dot)com>

On Wed, Nov 19, 2025 at 10:44 PM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
wrote:

> 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
>