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

Hi,

On Sun, Aug 2, 2026 at 10:28 PM shveta malik <shveta(dot)malik(at)gmail(dot)com> wrote:
>
> Bharath, I could not find any issue in my basic testing,

Thanks, Shveta, for reviewing!

> although I
> would like to understand this part a bit better:
>
> + if (isCommit)
> + {
> + acquiredInSubId = parentSubid;
> + return;
> + }
>
> How can we reach this block? In a non-error scenario, it seems that by
> the time AtEOSubXact_ReplicationSlot() is invoked, the slot has
> already been released, and we return earlier from 'if (acquiredInSubId
> != mySubid)' block. I could not find a case where:
>
> a) the slot is acquired in the current subtransaction, b) the
> subtransaction commits (isCommit == true), and c) the slot is still
> held when AtEOSubXact_ReplicationSlot() is invoked.
>
> Could you please explain what I am missing?

Yes, no caller hits this today. Each slot function releases the slot
before returning, so we take the early return and never reach the
commit branch with a slot still held. It is there for a future slot
function that acquires the slot but never releases it (rare case). On
commit we pass the slot to the parent so that if an ancestor later
aborts, the slot still gets released, the same way
AtEOSubXact_LargeObject() and AtEOSubXact_Files() do.

I checked this locally by making the pg_replication_slot_advance()
return while still holding the slot and running it through nested
PL/pgSQL exception blocks. With the handoff the outer abort releases
the slot, and dropping the handoff makes the slot leak and hit the
same issue reported in this thread. I can either enhance the comment
there to say it's currently unreachable and why we keep it, or turn it
into an assertion.

Thoughts?

--
Bharath Rupireddy
Amazon Web Services: https://aws.amazon.com