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

On Tue, Aug 4, 2026 at 5:03 PM Zhijie Hou (Fujitsu)
<houzj(dot)fnst(at)fujitsu(dot)com> wrote:
>
> On Tuesday, August 4, 2026 7:17 PM shveta malik <shveta(dot)malik(at)gmail(dot)com> wrote:
> >
> > On Tue, Aug 4, 2026 at 4:26 PM Zhijie Hou (Fujitsu)
> > <houzj(dot)fnst(at)fujitsu(dot)com> wrote:
> > >
> > > On Tuesday, August 4, 2026 4:39 PM Zhijie Hou (Fujitsu)
> > <houzj(dot)fnst(at)fujitsu(dot)com> wrote:
> > > > On Friday, July 31, 2026 3:12 AM Bharath Rupireddy
> > > > <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> wrote:
> > > > >
> > > > > I read the issue, patches and comments so far and here's my take on it.
> > > > >
> > > > > ...
> > > >
> > > > Thanks for sharing the patch.
> > > >
> > >
> > > The only thing I notice is that this new design seems to touch more scope than
> > > the original PG_TRY/PG_CATCH approach, since it releases the slot not only on
> > > ERROR but also on a manual transaction abort (a direct AbortCurrentTransaction()
> > > call without an intervening ERROR). It also seems slightly inconsistent that we
> > > do this for subtransactions but not for top-level transactions, but maybe it's
> > > OK as it only targets to fix the PL/pgSQL EXCEPTION case.
> > >
> > > One interesting case I thought of: we currently record
> > > GetCurrentSubTransactionId() when creating or acquiring a slot, and that ID is a
> > > logical subxid (starting from 1). So it looks possible for the following to
> > > happen: the user acquires the slot in a subtransaction with subxid 2 and commits
> > > the whole transaction; then, in a new transaction, the user starts a
> > > subtransaction that also gets subxid 2 and aborts it.
> >
> > IIUC, you are referring to the case which Bharath and myself discussed
> > in [1]. See [1] and previous few emails.
> >
> > > In that case the slot
> > > would be released, even though the aborted subtransaction is a different one
> > > from the subtransaction that originally acquired the slot.
> >
> > Even if that happens, I think it is covered because on Commit, patch
> > changes `acquiredInSubId` to parent-Id and thus a new subxid 2 will
> > not be releasing it.
>
> Right, I've confirmed that this can't happen. I'm OK with keeping this code,
> since it's future-proof - otherwise, others might raise the same concern I
> imagined above.
>

Okay, works for me, let's retain it. But good to change the comment to
indicate there is no such scenario at the moment, otherwise it may
confuse readers.

thanks
Shveta