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

From: Vitaly Davydov <v(dot)davydov(at)postgrespro(dot)ru>
To: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Deadlock detector fails to activate on a hot standby replica
Date: 2026-06-18 13:11:27
Message-ID: 279402b1-7f16-43fa-9dbf-df96a93245dd@postgrespro.ru
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Dear Fujii Masao,

Thank you for the v5 patch. It looks good for me.

> I still haven't come up with a good way to test this without depending on
> log_startup_progress_interval being active during standby WAL replay.
> Even so, I think the fix is still worth committing because it addresses
> a real issue. So how about committing 0001 patch first, even without
> a regression test?

I have no objections to commit the v5 patch without the tap-test. Once, it is
the bug fix, should we prepare the fix for other major branches? I'm ready to
prepare the patches based on the v5 version.

I looked at the tap test and found the reason why the test doesn't reproduce
the issue. The function adjust_conf in Cluster.pm changes the existing
parameter but doesn't add new new parameter to the configuration file if it is
missed. It doesn't report any errors as well. If to use the append_conf method
the test starts to reproduce the issue pretty stable, because the parameter is
actually added to the configuration file.

One more note - in my original test I set autovacuum = off for all nodes, but
in modified 031 test autovacuum seems to be enabled. Disabling autovacuum may
make the test more stable.

With best regards,
Vitaly

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2026-06-18 13:18:37 fix pg_mkdir_p to tolerate concurrent directory creation
Previous Message Tender Wang 2026-06-18 13:01:11 Re: assertion failure with unique index + partitioning + join