Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wbjS8-002nez-2J for pgsql-hackers@arkaria.postgresql.org; Mon, 22 Jun 2026 18:33:01 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wbjS7-007YYS-1q for pgsql-hackers@arkaria.postgresql.org; Mon, 22 Jun 2026 18:32:59 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wbjS7-007YYK-0M for pgsql-hackers@lists.postgresql.org; Mon, 22 Jun 2026 18:32:59 +0000 Received: from mail.postgrespro.ru ([93.174.132.70]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1wbjS4-00000001ctt-06ts for pgsql-hackers@lists.postgresql.org; Mon, 22 Jun 2026 18:32:57 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=postgrespro.ru; s=mx2023; t=1782153171; bh=cCBkVbT+Tr9Jo2zkj7+P8ja2EXEbgcf0F7nYFGvqLZ4=; h=Message-ID:Date:User-Agent:Subject:To:Cc:References:From: In-Reply-To:From; b=Um3LivBnyhJGhm2vzCQDTl3DxtlRWd5Z/lwX6dqeGTesi86wMCrUDii++fA/rogb1 kYYhV2/54wT2jxXruX1V8GIIFLZkjmBco6OBKG9SE5Ej+Qd1F0ifS6Z8FTS1spyqss KazmiJuwlDM82CriDmuFS1Gxze1PxCcmsV/NP1kZeMefqMezdi2xIBfJY0ClB36PRa i/cEJWcXl4QVvizUC+FohT4PoP+a0HVY4n5g1KDqVy9R6+ZQfWGwWfA+UMmVWdlxjS iyt+yayxqQAJhfQoeMtI614S7qnCQRI//ghG2wvP3foTpsmPvUaSn8EqTVAIJfFyj2 aQxX6GydayPIQ== Received: from [172.30.49.62] (debian11-template.l.postgrespro.ru [192.168.2.254]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: v.davydov@postgrespro.ru) by mail.postgrespro.ru (Postfix/465) with ESMTPSA id 33A1460B39; Mon, 22 Jun 2026 21:32:51 +0300 (MSK) Message-ID: <16cdffd4-f06c-4957-9132-1849a719f3d4@postgrespro.ru> Date: Mon, 22 Jun 2026 21:32:50 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Deadlock detector fails to activate on a hot standby replica To: Fujii Masao Cc: pgsql-hackers@lists.postgresql.org References: <44c24dcf-5710-410f-b1b6-d10b315f3d51@postgrespro.ru> <25cba756-9459-4811-aeaf-4a8715735c82@postgrespro.ru> <12324a50-95d3-4de4-bd89-b295924b35bb@postgrespro.ru> <279402b1-7f16-43fa-9dbf-df96a93245dd@postgrespro.ru> Content-Language: en-US From: Vitaly Davydov In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-KSMG-AntiPhishing: NotDetected X-KSMG-AntiSpam-Interceptor-Info: not scanned X-KSMG-AntiSpam-Status: not scanned, disabled by settings X-KSMG-AntiVirus: Kaspersky Secure Mail Gateway, version 3.0.0.9059, bases: 2026/06/22 15:47:00 #28269353 X-KSMG-AntiVirus-Status: NotDetected, skipped X-KSMG-LinksScanning: not scanned, disabled by settings X-KSMG-Message-Action: skipped X-KSMG-Rule-ID: 1 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Dear Fujii Masao, All While working on porting the patch to other majors, I've found that, the code in RegisterPinCountWaiter() (see below) should be improved because it doesn't unlock the bufHdr when the error is raised, as in LockBufferForCleanup(). I guess it works, but it keeps the locks a bit longer. RegisterPinCountWaiter v5 patch code: ... if ((buf_state & BM_PIN_COUNT_WAITER) != 0 && bufHdr->wait_backend_pgprocno != MyProcNumber) elog(ERROR, "multiple processes attempting to wait for pincount 1"); RegisterPinCountWaiter proposed changes: ... if ((buf_state & BM_PIN_COUNT_WAITER) != 0 && bufHdr->wait_backend_pgprocno != MyProcNumber) { UnlockBufHdr(bufHdr); elog(ERROR, "multiple processes attempting to wait for pincount 1"); } What do you think? With best regards, Vitaly