Thread

1. [PATCH] Fix WAIT FOR LSN standby_write/standby_flush for archive recovery cases

   SATYANARAYANA NARLAPURAM <satyanarlapuram@gmail.com> — 2026-04-15T06:44:23Z

   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/CAHg+QDdLmfpS0n0U3U+e+dw7X7jjEOsJJ0aLEsrtxs-tUyf5Ag@mail.gmail.com
   
   Thanks,
   Satya
   

2. Re: [PATCH] Fix WAIT FOR LSN standby_write/standby_flush for archive recovery cases

   Alexander Korotkov <aekorotkov@gmail.com> — 2026-04-16T07:31:01Z

   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
   
   
   
   

3. Re: [PATCH] Fix WAIT FOR LSN standby_write/standby_flush for archive recovery cases

   SATYANARAYANA NARLAPURAM <satyanarlapuram@gmail.com> — 2026-04-16T07:33:47Z

   Hi,
   
   On Thu, Apr 16, 2026 at 12:31 AM Alexander Korotkov <aekorotkov@gmail.com>
   wrote:
   
   > 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
   
   
   Thanks, I will review it.