On Tue, Aug 4, 2026 at 5:03 PM Zhijie Hou (Fujitsu) <[email protected]> wrote: > > On Tuesday, August 4, 2026 7:17 PM shveta malik <[email protected]> > wrote: > > > > On Tue, Aug 4, 2026 at 4:26 PM Zhijie Hou (Fujitsu) > > <[email protected]> wrote: > > > > > > On Tuesday, August 4, 2026 4:39 PM Zhijie Hou (Fujitsu) > > <[email protected]> wrote: > > > > On Friday, July 31, 2026 3:12 AM Bharath Rupireddy > > > > <[email protected]> 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
