Message-ID: <279402b1-7f16-43fa-9dbf-df96a93245dd@postgrespro.ru>
Date: Thu, 18 Jun 2026 16:11:27 +0300
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Deadlock detector fails to activate on a hot standby replica
To: Fujii Masao <masao.fujii@gmail.com>
Cc: pgsql-hackers@lists.postgresql.org
References: <44c24dcf-5710-410f-b1b6-d10b315f3d51@postgrespro.ru>
 <b178ea8d-9ed9-48b3-b4f7-5cfc3ff6ee44@postgrespro.ru>
 <CAHGQGwExVv1-mtPEX-JFGBXNY2r8DfP+sQVPD8GpDTefW0KdsQ@mail.gmail.com>
 <25cba756-9459-4811-aeaf-4a8715735c82@postgrespro.ru>
 <CAHGQGwFCqEkeaoUKHPJ5kpGjrKrJ5nzqE6NqjT-Rz3S6Zg7fug@mail.gmail.com>
 <CAHGQGwGNfwDH4hF_LnXzjnUd3d8+PF=f3dRbNn9XkL1hFbvRRQ@mail.gmail.com>
 <12324a50-95d3-4de4-bd89-b295924b35bb@postgrespro.ru>
 <CAHGQGwFED52rRVb_a=bVSdbOA=oARVOUyw381GC_6uKoNWJAtQ@mail.gmail.com>
 <b8f9bf41-8afa-46f5-9718-dc096bd666c0@postgrespro.ru>
 <CAHGQGwHh5j=sG3AZh=HyuXtPM6cmymp6MJkRAMJcJUyN2qpHrQ@mail.gmail.com>
 <CAHGQGwF01sOHnh6_9yDWiAdBMNnGWsTpM89+8XeztMjV=xk+cw@mail.gmail.com>
Content-Language: en-US
From: Vitaly Davydov <v.davydov@postgrespro.ru>
In-Reply-To: 
 <CAHGQGwF01sOHnh6_9yDWiAdBMNnGWsTpM89+8XeztMjV=xk+cw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/279402b1-7f16-43fa-9dbf-df96a93245dd%40postgrespro.ru>
Precedence: bulk

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