Re: [PATCH] Prevent repeated deadlock-check signals in standby buffer pin waits - Mailing list pgsql-hackers

From JoongHyuk Shin
Subject Re: [PATCH] Prevent repeated deadlock-check signals in standby buffer pin waits
Date
Msg-id CACSdjfNFb8KFbnp3=BAJfqXPRTgJiyP34R39ZWhxPy56GsCVLg@mail.gmail.com
Whole thread
In response to Re: sequencesync worker race with REFRESH SEQUENCES  (shveta malik <shveta.malik@gmail.com>)
Responses Re: [PATCH] Prevent repeated deadlock-check signals in standby buffer pin waits
List pgsql-hackers
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).

--
JH Shin

On Wed, May 20, 2026 at 7:15 AM Álvaro Herrera <alvherre@kurilemu.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 v20
> > 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,

--
Álvaro Herrera        Breisgau, Deutschland  —  https://www.EnterpriseDB.com/
"¿Qué importan los años?  Lo que realmente importa es comprobar que
a fin de cuentas la mejor edad de la vida es estar vivo"  (Mafalda)

pgsql-hackers by date:

Previous
From: Yugo Nagata
Date:
Subject: Re: Incremental View Maintenance, take 2
Next
From: shveta malik
Date:
Subject: Re: effective_wal_level is not decreasing after using REPACK (CONCURRENTLY)