Re: Implement waiting for wal lsn replay: reloaded

From: Andres Freund <andres(at)anarazel(dot)de>
To: Alexander Korotkov <aekorotkov(at)gmail(dot)com>
Cc: Xuneng Zhou <xunengzhou(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Peter Eisentraut <peter(at)eisentraut(dot)org>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Álvaro Herrera <alvherre(at)kurilemu(dot)de>, Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Michael Paquier <michael(at)paquier(dot)xyz>, jian he <jian(dot)universality(at)gmail(dot)com>, Tomas Vondra <tomas(at)vondra(dot)me>, Yura Sokolov <y(dot)sokolov(at)postgrespro(dot)ru>
Subject: Re: Implement waiting for wal lsn replay: reloaded
Date: 2026-04-08 00:50:11
Message-ID: 2eg4msihe4kbmwmxyoamgeeg5xj4fr2tlfj2omss3d3to2kveg@lbhhfggrdrw4
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2026-04-08 02:30:44 +0300, Alexander Korotkov wrote:
> On Tue, Apr 7, 2026 at 6:55 PM Xuneng Zhou <xunengzhou(at)gmail(dot)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.

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Chao Li 2026-04-08 01:03:33 Re: Add errdetail() with PID and UID about source of termination signal
Previous Message Thomas Munro 2026-04-08 00:30:46 Re: Automatically sizing the IO worker pool