On Wed, Apr 8, 2026 at 3:50 AM Andres Freund <[email protected]> wrote: > On 2026-04-08 02:30:44 +0300, Alexander Korotkov wrote: > > On Tue, Apr 7, 2026 at 6:55 PM Xuneng Zhou <[email protected]> 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
