Re: [PATCH] Release replication slot on error in SQL-callable slot functions

Hi,

On Mon, Aug 24, 2026 at 3:29 PM Bharath Rupireddy
<bharath(dot)rupireddyforpostgres(at)gmail(dot)com> wrote:
>
> On Fri, Aug 21, 2026 at 3:34 PM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
> >
> > I think we need to carefully think about whether we drop all temp
> > slots at subxact abort and when we do that.
> >
> > Also, is calling ReplicationSlotCleanup() (and possibly
> > ReplicationSlotRelease()) during sub-transaction abort really safe in
> > the first place? That function could raise errors and we call it out
> > of transactions elsewhere.
> >
> > I'm inclined to think AtEOSubXact_ReplicationSlot() should only
> > release the slot and not call ReplicationSlotCleanup() at all. That
> > said, I'm not fully convinced of this either as it might be
> > inconsistent with top-level error cases in a sense.
>
> Upon thinking about this more, I realize that temporary slot handling
> in the subxact error callback looks complicated and hard to reason
> about from the end user's perspective. I checked commit a924c327e27
> that introduced temporary slots. It seems like the behavior was kept
> simple: release at session end or upon error, without classifying
> whether the error came from slot handling or something else. Subxact
> errors caught by exception blocks are usually there to continue in the
> same transaction, not like top-level ERRORs. I think leaving temp slot
> cleanup out of subxact error handling and slightly modifying the docs
> seems fine.
>
> On whether it is safe to release the slot during subxact abort, that
> function could raise an error in one rare scenario (a file rename
> failure). I checked that when an error is thrown while releasing the
> slot invoked from PostgresMain()'s sigsetjmp handler, it re-enters
> that handler, and the resulting recursion eventually overflows the
> stack, causing a PANIC. The subxact abort path gets the same behavior
> when releasing the slot there.
>
> 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.
>
> Thoughts?

I removed the temporary slot handling in the code and tests and
attached the simplified v14 patch. I also adjusted the docs to mention
that temporary slots are not automatically dropped when an error is
raised and caught in a subtransaction.

--
Bharath Rupireddy
Amazon Web Services: https://aws.amazon.com