Subject: [PATCH] Fix WAIT FOR LSN standby_write/standby_flush for archive recovery cases

From: SATYANARAYANA NARLAPURAM <[email-masked]>
Date: Tue, 14 Apr 2026 23:44:23 -0700

Hi Alexnader, Hackers,

GetCurrentLSNForWaitType() for WAIT_LSN_TYPE_STANDBY_WRITE and
WAIT_LSN_TYPE_STANDBY_FLUSH previously relied on the WAL receiver's
tracked write/flush positions (GetWalRcvWriteRecPtr/GetWalRcvFlushRecPtr).
There are two scenarios where WAIT FOR LSN queries can be stalled though
replay is making progress. Breaking it down to two to give clarity on
setups but
the underlying problem is the same.

There are two scenarios here:

(1). When the standby is disconnected from the primary and switched to WAL
archive mode, it continues to be in that mode until no more WAL is
available to replay
and then switch to streaming mode. Until then WAIT FOR LSN calls get stuck
on the
standby though replay catches up beyond the stale WAL receiver position.
Switching
XLog source from archive to streaming is separately tracked in [1].

(2). In the case of Archive recovery, no WAL receiver process exists, so
these
functions return InvalidXLogRecPtr (0/0). WAIT FOR LSN with standby_flush or
standby_write modes would always time out, even for WAL that has been
fully replayed.

Fix by falling back to the replay LSN (GetXLogReplayRecPtr) when the WAL
receiver position is invalid or behind replay. This is correct because any
WAL that has been replayed has necessarily already been written and flushed
to disk. Attached the repro test case.

[1]:
https://www.postgresql.org/message-id/[email-masked]

Thanks,
Satya

---

From: Alexander Korotkov <[email-masked]>
Date: Thu, 16 Apr 2026 10:31:01 +0300

Hi, Satyanarayana!

On Wed, Apr 15, 2026 at 9:44 AM SATYANARAYANA NARLAPURAM
<[email-masked]> wrote:
> replay is making progress. Breaking it down to two to give clarity on setups but
> archive mode, it continues to be in that mode until no more WAL is available to replay
> and then switch to streaming mode. Until then WAIT FOR LSN calls get stuck on the
> standby though replay catches up beyond the stale WAL receiver position. Switching
> (2). In the case of Archive recovery, no WAL receiver process exists, so these

Please, check, similar patch is already posted here.

https://www.postgresql.org/message-id/CABPTF7Ukk8iJF7TpnK2mFOaboNJgWL1csfXu4e3J4GT0o7x0GQ%40mail.gmail.com

------
Regards,
Alexander Korotkov
Supabase

---

From: SATYANARAYANA NARLAPURAM <[email-masked]>
Date: Thu, 16 Apr 2026 00:33:47 -0700

Hi,

On Thu, Apr 16, 2026 at 12:31 AM Alexander Korotkov <[email-masked]>
wrote:

> > tracked write/flush positions
> (GetWalRcvWriteRecPtr/GetWalRcvFlushRecPtr).

Thanks, I will review it.