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.94.2) (envelope-from ) id 1ql8e1-001NVl-6s for pgsql-bugs@arkaria.postgresql.org; Tue, 26 Sep 2023 14:02:33 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1ql8dz-00CI2Z-K0 for pgsql-bugs@arkaria.postgresql.org; Tue, 26 Sep 2023 14:02:31 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1ql8dz-00CI2Q-Av for pgsql-bugs@lists.postgresql.org; Tue, 26 Sep 2023 14:02:31 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1ql8dw-007guO-BE for pgsql-bugs@lists.postgresql.org; Tue, 26 Sep 2023 14:02:30 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 38QE2PPO404710; Tue, 26 Sep 2023 10:02:25 -0400 From: Tom Lane To: Sorin Mircioiu cc: pgsql-bugs@lists.postgresql.org Subject: Re: PostgreSQL's processes blocking each other are not detected as deadlock In-reply-to: References: Comments: In-reply-to Sorin Mircioiu message dated "Tue, 26 Sep 2023 13:23:48 +0300" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <404708.1695736945.1@sss.pgh.pa.us> Date: Tue, 26 Sep 2023 10:02:25 -0400 Message-ID: <404709.1695736945@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Sorin Mircioiu writes: > I need answers to the following questions: > 1. 13502 is blocked by 21544 and 21544 is blocked by 13502. Why PostgreSQL > didn't detect this situation as a deadlock ? You have not demonstrated that these two processes are waiting for each other, only that they are waiting for something. The subset of data you presented is insufficient to conclude that a deadlock should have been reported. It does appear that some progress has been made since the previous deadlock, since neither process is waiting for the same thing it was waiting on as of the deadlock report. In the past we've seen cases where a deadlock existed but the server could not detect it because one step in the waits-for loop was implemented by client-side behavior rather than a server-visible lock request. Not saying that's happened here, but you might want to consider your application's behavior with that idea in mind. > why is ShareLock used for the locking system in my situation ? ShareLock on an XID is a different thing from ShareLock on a table. IIRC we request ShareLock on an XID as a way of waiting for the transaction using that XID to terminate, which is a need that only comes up in some edge cases like CREATE INDEX CONCURRENTLY. Have you identified exactly what statements those functions are executing? regards, tom lane