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 1uZtCd-009apR-LU for pgsql-general@arkaria.postgresql.org; Thu, 10 Jul 2025 15:28:51 +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 1uZtCb-00E8ee-Mu for pgsql-general@arkaria.postgresql.org; Thu, 10 Jul 2025 15:28:50 +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 1uZtCb-00E8eA-Bi for pgsql-general@lists.postgresql.org; Thu, 10 Jul 2025 15:28:49 +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.96) (envelope-from ) id 1uZtCZ-006b31-36 for pgsql-general@lists.postgresql.org; Thu, 10 Jul 2025 15:28:49 +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 56AFSkX01529240; Thu, 10 Jul 2025 11:28:46 -0400 From: Tom Lane To: Steve Baldwin cc: "pgsql-generallists.postgresql.org" Subject: Re: Lock timeout in commit In-reply-to: References: Comments: In-reply-to Steve Baldwin message dated "Thu, 10 Jul 2025 22:01:07 +1000" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1529238.1752161326.1@sss.pgh.pa.us> Date: Thu, 10 Jul 2025 11:28:46 -0400 Message-ID: <1529239.1752161326@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Steve Baldwin writes: > I'm occasionally seeing a lock timeout in a commit statement. For example: > 2025-07-10 08:56:07.225 UTC,"b2bc_api","b2bcreditonline",23592," > 10.124.230.241:60648",686f8022.5c28,55,"COMMIT",2025-07-10 08:56:02 > UTC,3984/10729,676737574,ERROR,55P03,"canceling statement due to lock > timeout",,,,,,"COMMIT",,,"098c62f7-bb76-4607-88da-120c6edee423","client > backend",,-2835399305386018931 > Am I right in thinking this is likely due to a deferred foreign key > constraint? Plausible guess perhaps, although FKs don't normally need strong locks. > I couldn't see any obvious clue in the log. Is there somewhere > else I can look? I think all you could do is monitor the pg_locks view and hope to catch the process in "waiting" state before it fails. It occurs to me to wonder though if we couldn't provide more context in the error about what lock is being waited for. regards, tom lane