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

Thanks for the reviews.

v3 attached.

* Emit "recovery still waiting" inside the function.
It now fires at deadlock_timeout instead of max_standby_streaming_delay
(Ilmar).

* Pass waitStart and &logged_recovery_conflict from the caller;
  the in-function branch reuses the same gate.

* An early-return alternative reopens a race in the
  SetStartupBufferPinWaitBufId(-1) gap; the lock path has
  no equivalent because its caller is structured differently.

* Covered by src/test/recovery/t/054_bufferpin_conflict_log_timing.pl
  (FAIL on v2, PASS on v3).

--
JH Shin

On Fri, May 29, 2026 at 3:31 PM Michael Paquier <michael@paquier.xyz> wrote:

> On Fri, May 22, 2026 at 05:41:03PM +0900, JoongHyuk Shin wrote:
> > This patch addresses the opposite,
> > deadlock_timeout does fire, but LockBufferForCleanup loops back and
> re-arms
> > it, so the signal repeats once per second.
>
> Right.  I don't really see why this should be backpatched.  One
> argument would be more consistency of this area of the code across all
> the stable branches, but the argument is kind of moot as this does not
> fix a problem, just improves a bit what we have.
> --
> Michael
>