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

On Tue, Aug 4, 2026 at 7:51 AM Bharath Rupireddy
<bharath(dot)rupireddyforpostgres(at)gmail(dot)com> wrote:
>
> 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).

Okay, so we are preparing for a future scenario where a slot may live
across subtransaction boundaries, although that is not possible at the
moment. I'm not sure whether we really need to handle that case right
now; perhaps this should simply be an Assert() for the time being (not
a strong opinion though). At the very least, we should update the
comment to mention this rationale. And let's see what others think
about it.

> 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