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 1wXuwn-003YcI-0F for pgsql-hackers@arkaria.postgresql.org; Fri, 12 Jun 2026 06:00:53 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wXuwl-0013n6-0c for pgsql-hackers@arkaria.postgresql.org; Fri, 12 Jun 2026 06:00:51 +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 1wXuwk-0013mx-2M for pgsql-hackers@lists.postgresql.org; Fri, 12 Jun 2026 06:00:50 +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 1wXuwh-00000002IRL-2XpA for pgsql-hackers@lists.postgresql.org; Fri, 12 Jun 2026 06:00:49 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=postgrespro.ru; s=mx2023; t=1781244043; bh=n58s9WGVFE8jIMWq4wTowmFYbJjNrlqtdxYY9XzNCp8=; h=Message-ID:Date:User-Agent:Subject:To:Cc:References:From: In-Reply-To:From; b=md0OluJgtrZctyWQOQh4bkOjqGs0oMQFNQNCO0TwG8VQRev96bTnDGDiiGEBM0WUk nZFLh39Sgjb4LTykIzxFmt36ke90JWXuI5FG7CfI+lrHsRiRmxJyaXcmjOXIVmPdvQ +L7JlMN/GNCXyM2wnbdi3Pp+OXdY3HQsX35vYkIXvKUzfupsPKbeSca9WRFRW18FFE zpTw/cOTgB29iG6GfSGZf8+UoknU93Srn4gTmVFJDrZaEsLxnzldJhn9i6xxQA9vfO ZkrfYuvP3kNIKs3MGtxWmO3tKziXL+k1koZgklcZl1eAaNrlJ1GtG3QXVEVsFbE0yn mln9x2dV8X6+Q== Received: from [192.168.23.100] (unknown [46.31.25.177]) (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 BE50D5FFD6; Fri, 12 Jun 2026 09:00:43 +0300 (MSK) Message-ID: Date: Fri, 12 Jun 2026 09:00:43 +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> Content-Language: en-US From: Vitaly Davydov In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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/12 05:00:00 #28232288 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, On 6/10/26 11:42, Fujii Masao wrote: > Could you review the v4 patches? I've got the issue with BM_PIN_COUNT_WAITER. The origin of the issue is that the other backend resets the flag before sending the notification (signal) to the waiter. I agree with your changes where this flag is set again. I would like to propose BufferIsReadyForCleanup function name instead of BufferShouldWaitForCleanupLockForStandby (and change the returning value semantics). There are other possible alternatives: BufferIsReadyForWriting, BufferIsReadyForExclusiveAccess or something else. The code will look like below: if (BufferIsReadyForCleanup(bufid + 1)) break; I've also found strange email in the commit messages like below: Author: masao.fujii I tried the modified 031 tap test but I do not see that it reproduces the issue on the version without the fix. My version of 031 tap test hangs without the fix. I haven't yet reviewed the tap test code at the moment, but I'm going to do it as well. Below one more note that is not directly related to the fix but may probably improve the code readability. 1. BufferIsReadyForCleanup can be re-used with some small modifications in LockBufferForCleanup like shown below: LockBuffer(buffer, BUFFER_LOCK_EXCLUSIVE); if (BufferIsReadyForCleanup()) { // log recovery conflict return; } In this case, we have to reset PM_PIN_COUNT_WAITER state in BufferIsReadyForCleanup: if (buf_refcount == 1) { bufHdr->wait_backend_procno = -1; PinCountWaitBuf = NULL; UnlockBufHdrExt(bufHdr, 0, PM_PIN_COUNT_WAITER); return false; } I may to prepare one more commit with this change. With best regards, Vitaly