On Wed, May 27, 2026 at 8:50 PM Zhijie Hou (Fujitsu) <[email protected]> wrote: > > Hi, > > While testing the slot release logic, I noticed a bug in > ReplicationSlotRelease() where it may access a replication slot array entry > that > has already been released by itself. > > The detail is: When releasing an ephemeral replication slot, > ReplicationSlotRelease() first drops the slot via > ReplicationSlotDropAcquired(). > After this point, the slot's shared memory slot array entry can be immediately > reused by another backend creating a new slot. > > However, ReplicationSlotRelease() continued executing common cleanup code that > still dereferenced the old slot pointer and updated shared memory fields such > as > effective_xmin. If the slot array entry had already been reallocated, these > writes could inadvertently affect a different, unrelated slot.
Good catch! > I am attaching a patch that avoids touching slot shared-memory state after > dropping an ephemeral slot. Keep the post-release shared-memory updates only > for > non-ephemeral slots, where the slot remains valid after release. Thanks for the patch! It looks good to me. Barring any objections, I will commit it. > I haven't attached a test for this fix, as the change is straightforward and > the > likelihood of encountering this bug is low, so it may not be worth adding test > cycles for it. +1 Regards, -- Fujii Masao
