Re: Deadlock detector fails to activate on a hot standby replica

Hi JoongHyuk,

Thanks for double-checking this.

On Fri, Nov 13, 2026 at 10:50 AM JoongHyuk Shin <sjh910805(at)gmail(dot)com> wrote:
>
> Hi Xuneng, Vitaly,
>
> I tested v10 on master 48938780c35, built with --enable-cassert
> --enable-debug --enable-tap-tests --enable-injection-points. The patches
> apply and build without warnings, and src/test/recovery passes. On
> master with only the injection points added, the two new
> unrelated-wakeup tests fail.
> I also woke startup with pg_log_backend_memory_contexts() during a
> buffer pin deadlock and a lock deadlock, with
> max_standby_streaming_delay = -1. On master, 7 of 8 runs (2 of 2 buffer
> pin, 5 of 6 lock) were still stuck 10 to 15 seconds later. v10 resolved
> all of them at about the same time as with no wakeup.

Good to hear. What I'm unsure of is the use of
pg_log_backend_memory_contexts as the trigger for the premature
wake-up. It works but seems somewhat hacky. Unfortunately, the test is
built on this, so it might be unfavored at the end. But it still has
its value for proving whether the fix works or not indirectly.

BTW, I've been coping with lots of issues related to the $subject
recently. It seems that replay could be held unwantedly for various
reasons spanning from features/bugs. What the fixes of them require
unanimously is a well-working deadlock checking protocol, which the
current thread contributed partly to. In production, a configured
max_standby_*_delay would cance players stalling the replay
eventually, even if the deadlock checking does not work well or their
dependency on replay is invisible to that checking. However, this
still seems undesirable, because it makes no sense to wait for the
backends which have already formed cycles with the startup -- they
would not progress and could consume most of, if not all, the budget
that other normal backends share, hence impacting the overall
availability.

> The race I reported on v7 is fixed too. I checked it by stopping
> startup in gdb inside the window.
>
> LGTM. I'll mark it Ready for Committer.

v10 has been green with CFBots for a while. +1 for the move.

--
Regards,
Xuneng Zhou
HighGo Software Co., Ltd.