On Friday, April 17, 2026 2:50 PM JoongHyuk Shin <sjh910805@gmail.com> 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
