MIME-Version: 1.0
References: 
 <CAHg+QDeHkMcLBKaBu6sxigL2gUsHXye3QQs14zKyD25BnPNAvA@mail.gmail.com>
 <CAPpHfdtKvFME6+-NPnbmQj0dYXWKD2kKm_OTrV22Oq68iYBMQw@mail.gmail.com>
In-Reply-To: 
 <CAPpHfdtKvFME6+-NPnbmQj0dYXWKD2kKm_OTrV22Oq68iYBMQw@mail.gmail.com>
From: SATYANARAYANA NARLAPURAM <satyanarlapuram@gmail.com>
Date: Thu, 16 Apr 2026 00:33:47 -0700
Message-ID: 
 <CAHg+QDdfXvJSPAGW2DwOPm1jXsbQJzEsX+Tq1stUzffZ-RGCxg@mail.gmail.com>
Subject: Re: [PATCH] Fix WAIT FOR LSN standby_write/standby_flush for archive
 recovery cases
To: Alexander Korotkov <aekorotkov@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Content-Type: multipart/alternative; boundary="00000000000027ea3a064f8edbd4"
Archived-At: 
 <https://www.postgresql.org/message-id/CAHg%2BQDdfXvJSPAGW2DwOPm1jXsbQJzEsX%2BTq1stUzffZ-RGCxg%40mail.gmail.com>
Precedence: bulk

--00000000000027ea3a064f8edbd4
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi,

On Thu, Apr 16, 2026 at 12:31=E2=80=AFAM Alexander Korotkov <aekorotkov@gma=
il.com>
wrote:

> Hi, Satyanarayana!
>
> On Wed, Apr 15, 2026 at 9:44=E2=80=AFAM 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 thoug=
h
> > 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, s=
o
> 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 WA=
L
> > 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/CABPTF7Ukk8iJF7TpnK2mFOaboNJgWL1csf=
Xu4e3J4GT0o7x0GQ%40mail.gmail.com


Thanks, I will review it.

--00000000000027ea3a064f8edbd4
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">Hi,</div><br><div class=3D"gmail_quote gm=
ail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, Apr 16, =
2026 at 12:31=E2=80=AFAM Alexander Korotkov &lt;<a href=3D"mailto:aekorotko=
v@gmail.com">aekorotkov@gmail.com</a>&gt; wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex">Hi, Satyanarayana!<br>
<br>
On Wed, Apr 15, 2026 at 9:44=E2=80=AFAM SATYANARAYANA NARLAPURAM<br>
&lt;<a href=3D"mailto:satyanarlapuram@gmail.com" target=3D"_blank">satyanar=
lapuram@gmail.com</a>&gt; wrote:<br>
&gt; GetCurrentLSNForWaitType() for WAIT_LSN_TYPE_STANDBY_WRITE and<br>
&gt; WAIT_LSN_TYPE_STANDBY_FLUSH previously relied on the WAL receiver&#39;=
s<br>
&gt; tracked write/flush positions (GetWalRcvWriteRecPtr/GetWalRcvFlushRecP=
tr).<br>
&gt; There are two scenarios where WAIT FOR LSN queries can be stalled thou=
gh<br>
&gt; replay is making progress. Breaking it down to two to give clarity on =
setups but<br>
&gt; the underlying problem is the same.<br>
&gt;<br>
&gt; There are two scenarios here:<br>
&gt;<br>
&gt; (1). When the standby is disconnected from the primary and switched to=
 WAL<br>
&gt; archive mode, it continues to be in that mode until no more WAL is ava=
ilable to replay<br>
&gt; and then switch to streaming mode. Until then WAIT FOR LSN calls get s=
tuck on the<br>
&gt; standby though replay catches up beyond the stale WAL receiver positio=
n. Switching<br>
&gt; XLog source from archive to streaming is separately tracked in [1].<br=
>
&gt;<br>
&gt; (2). In the case of Archive recovery, no WAL receiver process exists, =
so these<br>
&gt; functions return InvalidXLogRecPtr (0/0). WAIT FOR LSN with standby_fl=
ush or<br>
&gt; standby_write modes would always time out, even for WAL that has been<=
br>
&gt; fully replayed.<br>
&gt;<br>
&gt; Fix by falling back to the replay LSN (GetXLogReplayRecPtr) when the W=
AL<br>
&gt; receiver position is invalid or behind replay. This is correct because=
 any<br>
&gt; WAL that has been replayed has necessarily already been written and fl=
ushed<br>
&gt; to disk. Attached the repro test case.<br>
<br>
Please, check, similar patch is already posted here.<br>
<br>
<a href=3D"https://www.postgresql.org/message-id/CABPTF7Ukk8iJF7TpnK2mFOabo=
NJgWL1csfXu4e3J4GT0o7x0GQ%40mail.gmail.com" rel=3D"noreferrer" target=3D"_b=
lank">https://www.postgresql.org/message-id/CABPTF7Ukk8iJF7TpnK2mFOaboNJgWL=
1csfXu4e3J4GT0o7x0GQ%40mail.gmail.com</a></blockquote><div><br></div><div>T=
hanks, I will review it.<br></div></div></div>

--00000000000027ea3a064f8edbd4--