Hi, On Thu, Apr 16, 2026 at 12:31 AM Alexander Korotkov <[email protected]> wrote:
> Hi, Satyanarayana! > > On Wed, Apr 15, 2026 at 9:44 AM SATYANARAYANA NARLAPURAM > <[email protected]> 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 Thanks, I will review it.
