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