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. > > IIUC, the patch only handles releasing the slot when the subtransaction aborts > after ReplicationSlotCreate(), but it doesn't address the original repro[1]
Sorry, I misread the code and missed the new logic in ReplicationSlotAcquire(). It does fix all the issues. Please ignore above. 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. 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. I think the HEAD cannot create such a case using SQL APIs, so it might not be a serious issue, but just share it for reference. Maybe some comments are needed to hint user about the risk of this. Best Regards, Zhijie Hou
