On Fri, Aug 28, 2026 at 9:49 AM shveta malik <[email protected]> wrote: > > On Thu, Aug 27, 2026 at 6:00 PM Amit Kapila <[email protected]> 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.
