On Tue, Aug 4, 2026 at 7:51 AM Bharath Rupireddy <[email protected]> wrote: > > Hi, > > On Sun, Aug 2, 2026 at 10:28 PM shveta malik <[email protected]> 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
