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

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 the POC, and the attached patch builds on it.
>
> It releases the slot on subxact abort, at the subxact where it was
> acquired, instead of in each function. It records the subxact id that
> acquired the slot and, at every subxact end, checks whether that
> subxact is the one ending. On abort of the acquiring subxact it
> releases the slot. On commit it hands the id to the parent, so the
> slot is still released if the parent, or an ancestor, later aborts. A
> subxact id is used rather than a nesting level, since levels are
> reused.
>
> It does touch the subxact abort path, which is shared by all
> transactions, so it needs some care to not release the slot that
> logical decoding holds. As you noted, decoding starts and aborts an
> internal transaction (or subxact) per decoded transaction while
> holding the slot. That always happens below the acquiring subxact, so
> matching on the acquiring subxact id leaves those alone.
>
> Please have a look at the attached v7 patch.

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],
where the transaction aborts after ReplicationSlotAcquire() (e.g., erroring out
inside a SQL function such as pg_replication_slot_advance()). Could you
elaborate a bit on the feasibility of extending this design to cover that case?

[1] https://www.postgresql.org/message-id/CAHg%2BQDeuf9tCq3ce%3DkgFMJP0m%3DPZC%2Bwi6B%3DyS%2B7V0vNXjLS31w%40mail.gmail.com

Best Regards,
Zhijie Hou