On Fri, Nov 21, 2025 at 2:05 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
>
> On Thu, Nov 20, 2025 at 6:26 AM Fabrice Chapuis <fabrice636861@gmail.com> wrote:
> >
> > 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.
>
> Right.
>
> > Why not to use a slot's metadata (allow_overwrite) to treat these two situations separately.
>
> I'm not sure that the allow_overwrite idea is the best approach. For
> example, suppose that in a cascading replication setup (node-1 ->
> node2 -> node3) we create a failover slot on node2 (failover=true,
> synced=false, and allow_overwrite=false), the slot is synchronized to
> the node3 (failover=true, synced=true, allow_overwrite=false). If we
> do a switchover between node2 and node3, node3 joins the primary,
> node1, and node2 now joins node3 as a cascaded standby (i.e.,
> replication setup is now node1 -> node3 -> node2). I guess that in
> this case the slot on node2 wants to be overwritten by the one on the
> node3, but it's not allowed because the slot on node2 has
> allow_overwrite=false.
>
IIRC, we discussed the pg_alter_replication_slot() API which will
allow us to alter this new property (allow_overwrite or whatever we
name it) of slots and some existing properties like two_phase, etc.
--
With Regards,
Amit Kapila.
