Re: Implement waiting for wal lsn replay: reloaded - Mailing list pgsql-hackers

On Wed, Apr 8, 2026 at 3:50 AM Andres Freund <andres@anarazel.de> wrote:
> On 2026-04-08 02:30:44 +0300, Alexander Korotkov wrote:
> > On Tue, Apr 7, 2026 at 6:55 PM Xuneng Zhou <xunengzhou@gmail.com> wrote:
> > I agree to change in WaitLSNWakeup(), memory barrier looks necessary there.
> > Regarding GetCurrentLSNForWaitType(), I don't think barrier is needed
> > here, nor think it makes things clearer.  I think it would be enough
> > to comment that LWLock operations in addLSNWaiter()/deleteLSNWaiter()
> > provide necessary barriers.
>
> That's sufficient for the first iteration, but what guarantees it once you do
> WaitLatch()?  That's likely going to imply a barrier somewhere in the kernel,
> but I don't think there's any actual guarantee.

After WaitLatch(), ResetLatch() contains memory barrier.  And as I
understand, this memory barrier includes guarantees for reading fresh
values after WaitLatch() in typical latch usage scenario.  However, I
see in WaitForLSN() we can exit from WaitLatch() on timeout, and then
potentially exit from loop on timeout without rechecking for the most
fresh LSN.  I suppose we can just do ResetLatch() unconditionally to
fix that.

------
Regards,
Alexander Korotkov
Supabase