MIME-Version: 1.0
References: 
 <CACSdjfO3ox8i8N3KxGf3HThzX1vnRRkY2kq1m5qsvGxjcuM1jg@mail.gmail.com>
In-Reply-To: 
 <CACSdjfO3ox8i8N3KxGf3HThzX1vnRRkY2kq1m5qsvGxjcuM1jg@mail.gmail.com>
From: Fujii Masao <masao.fujii@gmail.com>
Date: Tue, 21 Apr 2026 14:42:38 +0900
Message-ID: 
 <CAHGQGwFqKOmLNiPhBYB0Bh1Akot=SbTpzMSHA-au4aqVa8PKog@mail.gmail.com>
Subject: Re: [PATCH] Prevent repeated deadlock-check signals in standby buffer
 pin waits
To: JoongHyuk Shin <sjh910805@gmail.com>
Cc: "pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CAHGQGwFqKOmLNiPhBYB0Bh1Akot%3DSbTpzMSHA-au4aqVa8PKog%40mail.gmail.com>
Precedence: bulk

On Sun, Apr 19, 2026 at 2:47=E2=80=AFPM JoongHyuk Shin <sjh910805@gmail.com=
> wrote:
>
> In ResolveRecoveryConflictWithBufferPin(), when deadlock_timeout fires,
> the function sends RECOVERY_CONFLICT_BUFFERPIN_DEADLOCK and returns.
> The caller (LockBufferForCleanup) loops back, sets up another deadlock_ti=
meout,
> and the signal gets sent again every interval.
>
> The lock-conflict path had the same problem and was fixed in 8900b5a9d59a
> by adding a second ProcWaitForSignal() after the deadlock-check signal.
> The buffer-pin path was left with an XXX comment asking "should we fix th=
is?".
>
> The attached patch applies the same fix: after sending the deadlock-check
> signal, reset got_standby_deadlock_timeout and call ProcWaitForSignal()
> so the startup process waits for UnpinBuffer() rather than looping
> and re-signaling.
>
> Patch attached.

Thanks for the patch! LGTM.

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 v20
development opens (probably July) before committing it.

While reading the patch and ResolveRecoveryConflictWithBufferPin(), I also
noticed that got_standby_delay_timeout is not initialized to false before
enabling the timeout. This is unrelated to the patch, and I think it is
harmless in the current code, but would it be better to initialize it there=
,
as we already do for got_standby_deadlock_timeout?

                    if (ltime !=3D 0)
                    {
    +                       got_standby_delay_timeout =3D false;
                            timeouts[cnt].id =3D STANDBY_TIMEOUT;
                            timeouts[cnt].type =3D TMPARAM_AT;
                            timeouts[cnt].fin_time =3D ltime;

Regards,

--=20
Fujii Masao