On Thu, Aug 27, 2026 at 11:58 AM Masahiko Sawada <[email protected]> wrote:
>
> On Mon, Aug 24, 2026 at 3:29 PM Bharath Rupireddy
> <[email protected]> wrote:
> >
> >
> > In short, having just the slot release in the subxact path gives the
> > same error behavior, is simple to reason about, and fixes the crash
> > reported in this thread.
>
> One thing I'm a bit concerned about is that this would be the first
> caller to invoke ReplicationSlotRelease() from inside the transaction
> machinery.
>
True, but OTOH, won't we already clean up resources not directly
associated with subxact in AtEOSubXact_LargeObject() or
AtEOSubXact_Files()? I don't see any problem as far as the current
pattern of usage for slots. The new restriction this patch will add is
"a slot acquired in a subxact does not survive that subxact being
unwound." which should be okay because of its similarity with
top-level xact behavior. I feel if possible we should restrict such
usage explicitly in code in some way rather than one finding out this
as a surprise.
*
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 $$;
The situation can be worse if one retries creating the slot in the
exception handler with a different name. Is it okay to leave such a
restriction as it-is by documenting or shall we try to deal with it at
least on HEAD?
--
With Regards,
Amit Kapila.
