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
