On Fri, Aug 28, 2026 at 9:49 AM shveta malik <shveta.malik@gmail.com> wrote:
>
> On Thu, Aug 27, 2026 at 6:00 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> >
> > *
> > An error raised and caught in a
> > + subtransaction, for example by a
> > + <application>PL/pgSQL</application> exception block, does not drop
> > + them.
> >
> > Based on above, something like below won't clean up temp slots and end
> > up holding xmin.
> > DO $$ BEGIN
> > PERFORM pg_create_logical_replication_slot('s', 'nonexistent_plugin', true);
> > EXCEPTION WHEN OTHERS THEN RAISE NOTICE '%', SQLERRM;
> > END $$;
>
> Well, on rethinking, I feel that if we encounter an error while
> creating a slot, whether persistent or temporary, the slot should be
> dropped right there.
>
> This already works correctly for persistent slots: by the time the
> slot reaches ReplicationSlotRelease, it is still in RS_EPHEMERAL state
> and is therefore dropped by release. OTIOH, a temporary slot is left
> behind. I think the temporary slot should also be dropped because the
> caller never received a reference to it. I don't see a legitimate use
> case where a temp slot should survive specifically because its
> creation call failed.
>
> The second case is an 'error while using an already-existing slot'
> (temporary or persistent). I think it is fine to let the temporary
> slot survive (similar to a persistent slot) in this case, consistent
> with what we've documented: the caller has a reference to the temp
> slot and can continue using it even after a caught subtransaction
> failure.
>
+1.
--
With Regards,
Amit Kapila.
