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

From Xuneng Zhou
Subject Re: Implement waiting for wal lsn replay: reloaded
Date
Msg-id CABPTF7WiDtWCR82geyaaaCRV9UiPR5YUHRNDysD_7Ltr1ymfug@mail.gmail.com
Whole thread Raw
In response to Re: Implement waiting for wal lsn replay: reloaded  (Alexander Korotkov <aekorotkov@gmail.com>)
Responses Re: Implement waiting for wal lsn replay: reloaded
List pgsql-hackers
Hi Alexander,

On Sun, Apr 5, 2026 at 8:31 PM Alexander Korotkov <aekorotkov@gmail.com> wrote:
>
> On Thu, Jan 29, 2026 at 9:47 AM Alexander Korotkov <aekorotkov@gmail.com> wrote:
> > On Tue, Jan 27, 2026 at 3:14 AM Xuneng Zhou <xunengzhou@gmail.com> wrote:
> > > Heikki spotted a misplaced wake-up call for replay waiters in
> > > PerformWalRecovery. He suggested that the WaitLSNWakeup needs to be
> > > invoked immediately after wal record is applied to avoid the potential
> > > missed wake-ups when recovery stops/pauses/promotes. It makes sense to
> > > me. Please check the attached patch to fix that.
> >
> > Pushed, thank you!
>
> I've assembled small patches, which I think worth pushing before v19 FF.
>
> 1. Avoid syscache lookup in WaitStmtResultDesc().  This is [1] patch,
> but I've removed redundant comment in ExecWaitStmt(), which explained
> the same as WaitStmtResultDesc() comment.
> 2. Use WAIT FOR LSN in wait_for_catchup().  I made the following
> changes: fallback to polling on not_in_recovery result instead of
> croaking, avoid separate pg_is_in_recovery() query, comment why we
> may face the recovery conflict and why it is safe to detect this by
> the error string.
> 3. A paragraph to the docs about possible recovery conflicts and their reason.
>
> I'm going to push this on Monday if no objections.
>
> Links.
> 1. https://www.postgresql.org/message-id/CABPTF7U%2BSUnJX_woQYGe%3D%3DR9Oz%2B-V6X0VO2stBLPGfJmH_LEhw%40mail.gmail.com
> 2. https://www.postgresql.org/message-id/CABPTF7X0n%3DR50z2fBpj3EbYYz04Ab0-DHJa%2BJfoAEny62QmUdg%40mail.gmail.com

I'll review them shortly.


--
Best,
Xuneng



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Shmem allocated wrong for custom cumulative stats
Next
From: Richard Guo
Date:
Subject: Re: Asynchronous MergeAppend