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 1seRmv-007EVk-0e for pgsql-admin@arkaria.postgresql.org; Thu, 15 Aug 2024 04:08:37 +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 1seRms-00EVDK-VF for pgsql-admin@arkaria.postgresql.org; Thu, 15 Aug 2024 04:08:34 +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.94.2) (envelope-from ) id 1seRms-00EVD6-Jm for pgsql-admin@lists.postgresql.org; Thu, 15 Aug 2024 04:08:34 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1seRmq-004nvH-4M for pgsql-admin@postgresql.org; Thu, 15 Aug 2024 04:08:33 +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 47F48SkT383013; Thu, 15 Aug 2024 00:08:28 -0400 From: Tom Lane To: Scott Ribe cc: Wasim Devale , pgsql-admin Subject: Re: Dead lock after the migration from CentOS 7 to RHEL 9 In-reply-to: <07994165-F268-41E0-9975-4FB5DE2EBED1@elevated-dev.com> References: <07994165-F268-41E0-9975-4FB5DE2EBED1@elevated-dev.com> Comments: In-reply-to Scott Ribe message dated "Wed, 14 Aug 2024 21:45:29 -0600" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <383011.1723694908.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Thu, 15 Aug 2024 00:08:28 -0400 Message-ID: <383012.1723694908@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Scott Ribe writes: > Given errors like the pair you posted, my next step would be to examine = the queries being executed by those processes during the deadlock. Now, I = think by the time the deadlock error is logged, the queries involved have = been cancelled, so it's possible the processes have gone on to another que= ry and so pg_stat_activity might not have useful information, or it might-= -depending on what your app would do after a deadlock error. > If it does not, then the next thing would be to set log_min_duration_sta= tement to less than deadlock/statement timeout, so that you could look thr= ough logs to figure out what are the two queries which are deadlocking aga= inst each other. The postmaster log should already contain the statements that deadlocked against each other --- that's what the "HINT: See server log for query details" is telling you. regards, tom lane