public inbox for [email protected]  

help / color / mirror / Atom feed

From: SATYANARAYANA NARLAPURAM <[email protected]>
To: Alexander Korotkov <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Subject: Re: [PATCH] Fix WAIT FOR LSN standby_write/standby_flush for archive recovery cases
Date: Thu, 16 Apr 2026 00:33:47 -0700
Message-ID: <CAHg+QDdfXvJSPAGW2DwOPm1jXsbQJzEsX+Tq1stUzffZ-RGCxg@mail.gmail.com> (raw)
In-Reply-To: <CAPpHfdtKvFME6+-NPnbmQj0dYXWKD2kKm_OTrV22Oq68iYBMQw@mail.gmail.com>
References: <CAHg+QDeHkMcLBKaBu6sxigL2gUsHXye3QQs14zKyD25BnPNAvA@mail.gmail.com>
	<CAPpHfdtKvFME6+-NPnbmQj0dYXWKD2kKm_OTrV22Oq68iYBMQw@mail.gmail.com>

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.gma...


Thanks, I will review it.

view thread (3+ messages)

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected]
  Subject: Re: [PATCH] Fix WAIT FOR LSN standby_write/standby_flush for archive recovery cases
  In-Reply-To: <CAHg+QDdfXvJSPAGW2DwOPm1jXsbQJzEsX+Tq1stUzffZ-RGCxg@mail.gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox