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

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.
>
> 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