MIME-Version: 1.0
References: <aecRYWJmfQnuVDBe@paquier.xyz> <agt3Aez4a51JC5Ji@alvherre.pgsql>
In-Reply-To: <agt3Aez4a51JC5Ji@alvherre.pgsql>
From: JoongHyuk Shin <sjh910805@gmail.com>
Date: Fri, 22 May 2026 17:41:03 +0900
Message-ID: 
 <CACSdjfNFb8KFbnp3=BAJfqXPRTgJiyP34R39ZWhxPy56GsCVLg@mail.gmail.com>
Subject: Re: [PATCH] Prevent repeated deadlock-check signals in standby buffer
 pin waits
To: =?UTF-8?Q?=C3=81lvaro_Herrera?= <alvherre@kurilemu.de>
Cc: Michael Paquier <michael@paquier.xyz>,
 Fujii Masao <masao.fujii@gmail.com>,
	"pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>,
	Vitaly Davydov <v.davydov@postgrespro.ru>
Content-Type: multipart/alternative; boundary="000000000000f67a3f065263fdf1"
Archived-At: 
 <https://www.postgresql.org/message-id/CACSdjfNFb8KFbnp3%3DBAJfqXPRTgJiyP34R39ZWhxPy56GsCVLg%40mail.gmail.com>
Precedence: bulk

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

Hello.

Same function, different races, I think.
Vitaly reports a missed wake-up where deadlock_timeout never fires
(spurious SIGALRM from log_startup_progress_interval plus the lazy
setitimer in 09cf1d52).
This patch addresses the opposite,
deadlock_timeout does fire, but LockBufferForCleanup loops back and re-arms
it,
so the signal repeats once per second.

The two fixes do not overlap
(the added ProcWaitForSignal sits inside the deadlock branch that Vitaly's
scenario never reaches).

--=20
JH Shin

On Wed, May 20, 2026 at 7:15=E2=80=AFAM =C3=81lvaro Herrera <alvherre@kuril=
emu.de> wrote:

> Hello,
>
> On 2026-Apr-21, Michael Paquier wrote:
>
> > On Tue, Apr 21, 2026 at 02:42:38PM +0900, Fujii Masao wrote:
> > > Since this change improves recovery-conflict behavior rather than
> fixing a bug,
> > > it doesn't seem to need backpatching and we may need to wait until v2=
0
> > > development opens (probably July) before committing it.
> >
> > Yeah, this one is an improvement, not an actual bug, so let's wait for
> > v20 if worth doing (I did not check it).
>
> Hmm, is this related to
> https://postgr.es/m/44c24dcf-5710-410f-b1b6-d10b315f3d51@postgrespro.ru ?
> In there, Vitaly claims to be reporting a bug that goes back to pg15,
> which contradicts this assessment.
>
> Regards,
>
> --
> =C3=81lvaro Herrera        Breisgau, Deutschland  =E2=80=94
> https://www.EnterpriseDB.com/
> "=C2=BFQu=C3=A9 importan los a=C3=B1os?  Lo que realmente importa es comp=
robar que
> a fin de cuentas la mejor edad de la vida es estar vivo"  (Mafalda)
>

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

<div dir=3D"ltr">Hello.<br><br>Same function, different races, I think.<br>=
Vitaly reports a missed wake-up where deadlock_timeout never fires <br>(spu=
rious SIGALRM from log_startup_progress_interval plus the lazy setitimer in=
 09cf1d52).<br>This patch addresses the opposite,<br>deadlock_timeout does =
fire, but LockBufferForCleanup loops back and re-arms it,<br>so the signal =
repeats once per second.<br><br>The two fixes do not overlap <br>(the added=
 ProcWaitForSignal sits inside the deadlock branch that Vitaly&#39;s scenar=
io never reaches).<br><br>-- <br>JH Shin</div><br><div class=3D"gmail_quote=
 gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, May 2=
0, 2026 at 7:15=E2=80=AFAM =C3=81lvaro Herrera &lt;<a href=3D"mailto:alvher=
re@kurilemu.de">alvherre@kurilemu.de</a>&gt; wrote:<br></div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid=
 rgb(204,204,204);padding-left:1ex">Hello,<br>
<br>
On 2026-Apr-21, Michael Paquier wrote:<br>
<br>
&gt; On Tue, Apr 21, 2026 at 02:42:38PM +0900, Fujii Masao wrote:<br>
&gt; &gt; Since this change improves recovery-conflict behavior rather than=
 fixing a bug,<br>
&gt; &gt; it doesn&#39;t seem to need backpatching and we may need to wait =
until v20<br>
&gt; &gt; development opens (probably July) before committing it.<br>
&gt; <br>
&gt; Yeah, this one is an improvement, not an actual bug, so let&#39;s wait=
 for<br>
&gt; v20 if worth doing (I did not check it). <br>
<br>
Hmm, is this related to <br>
<a href=3D"https://postgr.es/m/44c24dcf-5710-410f-b1b6-d10b315f3d51@postgre=
spro.ru" rel=3D"noreferrer" target=3D"_blank">https://postgr.es/m/44c24dcf-=
5710-410f-b1b6-d10b315f3d51@postgrespro.ru</a> ?<br>
In there, Vitaly claims to be reporting a bug that goes back to pg15,<br>
which contradicts this assessment.<br>
<br>
Regards,<br>
<br>
-- <br>
=C3=81lvaro Herrera=C2=A0 =C2=A0 =C2=A0 =C2=A0 Breisgau, Deutschland=C2=A0 =
=E2=80=94=C2=A0 <a href=3D"https://www.EnterpriseDB.com/" rel=3D"noreferrer=
" target=3D"_blank">https://www.EnterpriseDB.com/</a><br>
&quot;=C2=BFQu=C3=A9 importan los a=C3=B1os?=C2=A0 Lo que realmente importa=
 es comprobar que<br>
a fin de cuentas la mejor edad de la vida es estar vivo&quot;=C2=A0 (Mafald=
a)<br>
</blockquote></div>

--000000000000f67a3f065263fdf1--