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 1x14iE-004y1J-23 for pgsql-hackers@arkaria.postgresql.org; Mon, 31 Aug 2026 16:18:22 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1x14iC-001Fl1-08 for pgsql-hackers@arkaria.postgresql.org; Mon, 31 Aug 2026 16:18:20 +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 1x14iB-001Fkt-2N for pgsql-hackers@lists.postgresql.org; Mon, 31 Aug 2026 16:18:19 +0000 Received: from mail-lj1-x236.google.com ([2a00:1450:4864:20::236]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1x14iA-00000003KN1-0y8n for pgsql-hackers@lists.postgresql.org; Mon, 31 Aug 2026 16:18:18 +0000 Received: by mail-lj1-x236.google.com with SMTP id 38308e7fff4ca-3a1a3bb6c5dso30222811fa.2 for ; Mon, 31 Aug 2026 09:18:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1788193096; x=1788797896; darn=lists.postgresql.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=LVlQ4f8PuJd0GlZ5bL0yFUQhJGaF1WW/Txc6FI6mljU=; b=ROSs6RlbqQ07n0DFtpG1sbLeQpJ599hLBlgSl9l0hgicQHpUa/2hvQseYnzVSdZIhX YWAkxz2TISQWTwsigJ70h16JZSBnlMBnTGCnmgCLCD8jzGpIr3nPRQLX2u0AOU2aLVd1 wrwFSIb+oqiTot/25CGvKSvJcxuIcno9Nw7Sd5z3mcyU4GkvnsQdRO+sgp6IrICy7BpK rdidEqd9in4/yEd1O3zi2/F5mpwrlntGl+OAg/x1DALn6ebjdeupuT2IV1Vc5Ebgo/Bt 5JvLvW7RKuJqkRVwOc7T4MsIaIPA/ybcBRFbPw8ubKP4z9R7oXMdeoNEHzNwJoCeFsEW lrJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788193096; x=1788797896; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=LVlQ4f8PuJd0GlZ5bL0yFUQhJGaF1WW/Txc6FI6mljU=; b=pt/V3RPvX3EY4PJkroq7FGfZY3u+jXqnZPhcrhlmNsFxJiJrasDyx9meSoWmoxjqXv RCFOY7kYk1ECSrjdv3tQM3Araf4AZDfxd2yYGvkh5T6snfdQMvC56nG3gvgmgbiRvHGB P/eQ6J2e04IhybqLkFnly/6G+rZck+LNpEplC+u3fbjluXsx8IWRcmmDuN0Q1F9jBVSc tnMLmziuKzNksFF3raAQrkb3YcbamxLfBAa93EEw+hCbBRKuLj+8lbazFiXt5KeQNDvy m9rchzvV/d8csY+ljP1zZNFRwDAusy3FtnbN6CiIOyOsHyETb1T+5UrxdRh4WHHY3IcQ x2YA== X-Gm-Message-State: AFuF++kuH/LPikxuIwbWneZ+bWC7fqhDKgG5hs0c3ekdzHbLbFsXHWdu YVA9Zix8MpkWGUZL0y+mGb5YhZRNahUdDyxVTJZO+W3dnl+BVsG+NTa7 X-Gm-Gg: AYBFou1d6w9qFW26LQ7k4jvjKos+esHSfaGTQoQT2n9dcjogOTWceoQF7hneg2/2byQ BTQaGrVryr5IUrQsrZYZymRL0SkaNC7l4C755JArnLmAMpIcyTHIwdjLa5slSpBKf1giydj+sdf a9R2f3jZ5Fyhi6LUXSMyaXkknkyO7TpspTPJ1B/ELuCN1AjPdKSPMRZ97C8iJ6VrrOLH0yDXhTQ BTmnVOnuOqahSxbwIFMorAcDvdk6fmH3PHmosiWuqDYrB8e5OzKawR2yr3ATsLoL9BcPO/0na51 qGgID3VwRZH+YOmp+9wJ8k0quOBtOKu+hzymsqoPBoE97vOnyPDG88fGvfX1b/MO2z9vZGFpU/+ fm42No42OJKkspG+aBTb+dmFvuqZ3G1xWuyv4G8bWRrC5FRhFP93qwEnX4Ofnzu5uhALgBxcEKn kbQoJvwnhhbwFubcKP2Gwl3ZY+IJ5axOrArF/AC6JLDduw+O3PMhQKnx+7NuyA X-Received: by 2002:a05:651c:241:b0:3a1:f671:b2ee with SMTP id 38308e7fff4ca-3a301b141a8mr55851881fa.8.1788193096148; Mon, 31 Aug 2026 09:18:16 -0700 (PDT) Received: from [192.168.23.224] ([46.31.30.25]) by smtp.gmail.com with ESMTPSA id 38308e7fff4ca-3a3053bf589sm18598101fa.12.2026.08.31.09.18.15 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 31 Aug 2026 09:18:15 -0700 (PDT) Message-ID: <7e4f2244-4fd8-4f30-9f61-d1087e4b3292@gmail.com> Date: Mon, 31 Aug 2026 19:18:14 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Deadlock detector fails to activate on a hot standby replica To: JoongHyuk Shin , Xuneng Zhou Cc: pgsql-hackers@lists.postgresql.org, Fujii Masao References: <44c24dcf-5710-410f-b1b6-d10b315f3d51@postgrespro.ru> <7b1e8353-3d0a-48a1-bac6-2ac6ca91fbde@postgrespro.ru> <5c50d50c-5a9c-4a9e-9592-183cf4de1c80@postgrespro.ru> <52971629-dcda-4687-90c8-bbba3ce05636@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 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hi JH Shin, > I think PinCountWaiterCheckReadyForCleanup() has a window between > checking the refcount and setting BM_PIN_COUNT_WAITER. On the master > branch, UnpinBufferNoOwner() drops pins without taking the header > lock, so the last other pin can go away in that window and the > wakeup is lost until the deadlock or standby-limit timeout fires. > This looks like the same race that commit 8d85cb889a3 fixed in > LockBufferForCleanup(), and the same fix should work here. After > publishing the flag, recheck the refcount, and if only our own pin > remains, clear the flag and return true. Agree, thank you. I made new changes in two commits. In the first commit coming from v7 patch I modified RegisterPinCountWaiter() function to recheck the refcount as explained by you. In the second commit I've replaced the duplicate code in LockBufferForCleanup to register pincount waiter with the call of RegisterPinCountWaiter(). The second commit is optional but it fits well with the current changes. The patch was rebased to the actual master branch. P.S. I replaced my old address v.davydov@postgrespro.ru in commits with my personal email vitprof@gmail.com that suits better for me. With best regards, Vitaly Davydov vitprof@gmail.com (aka v.davydov@postgrespro.ru) vitcpp@mail.ru