Hi, Satyanarayana!
On Wed, Apr 15, 2026 at 9:44 AM SATYANARAYANA NARLAPURAM
<satyanarlapuram@gmail.com> wrote:
> 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.
Please, check, similar patch is already posted here.
https://www.postgresql.org/message-id/CABPTF7Ukk8iJF7TpnK2mFOaboNJgWL1csfXu4e3J4GT0o7x0GQ%40mail.gmail.com
------
Regards,
Alexander Korotkov
Supabase
