Re: Implement waiting for wal lsn replay: reloaded

From: Alexander Korotkov <aekorotkov(at)gmail(dot)com>
To: Xuneng Zhou <xunengzhou(at)gmail(dot)com>
Cc: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Peter Eisentraut <peter(at)eisentraut(dot)org>, Andres Freund <andres(at)anarazel(dot)de>, 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-05 12:31:46
Message-ID: CAPpHfds7oSCbZqob7ytT_Lso8fv-NW8LnedUTE4Krde+3rkJeA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Jan 29, 2026 at 9:47 AM Alexander Korotkov <aekorotkov(at)gmail(dot)com> wrote:
> On Tue, Jan 27, 2026 at 3:14 AM Xuneng Zhou <xunengzhou(at)gmail(dot)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

------
Regards,
Alexander Korotkov
Supabase

Attachment Content-Type Size
v3-0001-Avoid-syscache-lookup-while-building-a-WAIT-FOR-t.patch application/octet-stream 1.8 KB
v3-0003-Document-that-WAIT-FOR-may-be-interrupted-by-reco.patch application/octet-stream 1.5 KB
v3-0002-Use-WAIT-FOR-LSN-in-PostgreSQL-Test-Cluster-wait_.patch application/octet-stream 7.0 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Lukas Fittl 2026-04-05 12:31:53 Re: Stack-based tracking of per-node WAL/buffer usage
Previous Message Michael Paquier 2026-04-05 12:04:53 Re: Refactor query normalization into core query jumbling