Hi Zhijie, Thanks for pointing this out. You're right that my patch only covers the read side and misses the write side in ReplicationSlotReserveWal(). I should have checked for existing work before submitting.
I'll withdraw this patch. Best Regards, JoongHyuk Shin On Fri, Apr 17, 2026 at 3:59 PM Zhijie Hou (Fujitsu) <[email protected]> wrote: > On Friday, April 17, 2026 2:50 PM JoongHyuk Shin <[email protected]> > wrote: > > Commit 2a5225b99d7 fixed a race in ReplicationSlotsComputeRequiredXmin() > > where ReplicationSlotControlLock was released before the global xmin > > update, allowing a concurrent backend to overwrite a correct value with > > a stale one. > > > > ReplicationSlotsComputeRequiredLSN() has the same problem, > > it releases the lock before calling XLogSetReplicationSlotMinimumLSN(), > > so a stale minimum LSN can overwrite a correct (lower) one, > > potentially leading to premature WAL removal. > > > > The attached patch moves LWLockRelease() to after the LSN update, > > matching the xmin fix. > > Since 2a5225b99d7 was backpatched to all supported versions, > > I believe this should be as well. > > Thanks for noticing this. There is an existing thread [1] that I started > following 2a5225b99d7 to address the same issue. The patch you posted > only increases the lock scope in ReplicationSlotsComputeRequiredLSN() but > does > not increase the lock level when reserving WALs, so I think it would not > fix the issue. > > Please feel free to review the patch in that thread if you find it helpful. > > [1] https://commitfest.postgresql.org/patch/6451/ > > Best Regards, > Hou zj >
