Re: Implement waiting for wal lsn replay: reloaded

On Thu, Apr 9, 2026 at 11:21 PM Alexander Korotkov <aekorotkov(at)gmail(dot)com> wrote:
>
> On Wed, Apr 8, 2026 at 7:59 AM Xuneng Zhou <xunengzhou(at)gmail(dot)com> wrote:
> > > > Patch 0001 looks OK for me.
> > > > Regarding patch 0002. Changes made for GetCurrentLSNForWaitType()
> > > > looks reliable for me. PerformWalRecovery() sets replayed positions
> > > > before starting recovery, and in turn before standby can accept
> > > > connections. So, changes to WalReceiverMain() don't look necessary to
> > > > me.
> > >
> > > Yeah, GetCurrentLSNForWaitType seems to be the right place to place
> > > the fix. Please see the attached patch 2.
> > >
> > > I also noticed another relevent problem:
> > >
> > > During pure archive recovery (no walreceiver), a backend that issues
> > > 'WAIT FOR LSN ... MODE 'standby_write' with a target ahead of the
> > > current replay position will sleep forever; the startup process
> > > replays past the target but only wakes 'STANDBY_REPLAY' waiters.
> > >
> > > This also affects mixed scenarios: the walreceiver may lag behind
> > > replay (e.g., archive restore has delivered WAL faster than
> > > streaming), so a 'standby_write' waiter could be waiting on WAL that
> > > replay has already consumed.
> > >
> > > I will write a patch to address this soon.
> > >
> >
> > Here is the patch.
>
> I've assembled all the pending patches together.
> 0001 adds memory barrier to GetWalRcvWriteRecPtr() as suggested by
> Andres off-list.
> 0002 is basically [1] by Xuneng, but revised given we have a memory
> barrier in 0001, and my proposal to do ResetLatch() unconditionally
> similar to our other Latch-based loops.
> 0003 and 0004 are [2] by Xuneng.
> 0005 is [3] by Xuneng.
>
> I'm going to add them to Commitfest to run CI over them, and have a
> closer look over them tomorrow.
>
>
> Links.
> 1. https://www.postgresql.org/message-id/CABPTF7Wjk_FbOghyr09Rzu6T2bh-L_KBMqHK%2BzhRXpssU0STyQ%40mail.gmail.com
> 2. https://www.postgresql.org/message-id/CABPTF7X0iV%3DkGC4gjsTj4NvK_NNEJGM3YTc7Obxs5GOiYoMhEw%40mail.gmail.com
> 3. https://www.postgresql.org/message-id/CABPTF7UBdEfyxATWntmCfoJrwB6iPrnhkXO7y_Avmqc2bOn27A%40mail.gmail.com

I've added the patches to Commitfest.

[1] https://commitfest.postgresql.org/patch/6678/

--
Best,
Xuneng