Hi, On Mon, Aug 10, 2026 at 11:16 PM shveta malik <[email protected]> wrote: > > > I will drop both asserts and > > keep a short comment explaining why the slot is still held here. The > > existing AtEOSubXact_LargeObject() and AtEOSubXact_Files() don't check > > the passed-in mySubid for invalid either. > > > > Does the following work for you? > > > > /* > > * The aborting subxact is the one that acquired the slot, so the slot is > > * still held and must be released. acquiredInSubId is set only when a slot > > * is held and cleared when it is released, so a matching subxact id means > > * the slot is ours. > > */ > > ReplicationSlotRelease(); > > I am okay with this comment. No 'MyReplicationSlot-null' check and no assert.
Thanks. Done so in the attached v12 patch. Please have a look. -- Bharath Rupireddy Amazon Web Services: https://aws.amazon.com
v12-0001-Fix-replication-slot-leak-on-error-caught-in-a-s.patch
Description: Binary data
