Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oSxCZ-0003eG-I4 for pgsql-bugs@arkaria.postgresql.org; Tue, 30 Aug 2022 09:06:31 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1oSxCY-0006jC-BO for pgsql-bugs@arkaria.postgresql.org; Tue, 30 Aug 2022 09:06:30 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oSxCX-0006ib-AE for pgsql-bugs@lists.postgresql.org; Tue, 30 Aug 2022 09:06:30 +0000 Received: from out1-smtp.messagingengine.com ([66.111.4.25]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oSxCU-00061R-JN for pgsql-bugs@lists.postgresql.org; Tue, 30 Aug 2022 09:06:28 +0000 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id C22785C0070; Tue, 30 Aug 2022 05:06:21 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Tue, 30 Aug 2022 05:06:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:reply-to:sender :subject:subject:to:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; t=1661850381; x=1661936781; bh=h dU4KYPaHajBiRIU80FIx4DMsORKEKFe11ZGurCm0HE=; b=U1IAFH8H9Z60TAs8a j0x/uh1vZ8lQQTR5schKPDq4tlNrGntsHLE9V3QbmdT854Z1IKqm8we+f+AJAXT5 kI6bK4PsotFPLreaX+3Atcw9Gv5LHyG9D9Tkhq3b/N5nqiF0iqv4adFyg0T1AJtz ry8NUhYhjqOtIZjBOTHjHemqHnBSAa1JttZdgkqiZFHoKh/WBImSQKWiWh2opHtp eSlHWp2M5ui0Rtkdv8Sx9hqjBAvvZpSV3vquFJWxLRZXJTDh48xGveyuElijLA8N QzNIsMXnyEtG6kIn6e8gQnsstveE0M9WdrbPuXz5N+0F+84fCoHPtY4vRN1SdnDS QShSQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrvdekfedguddvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvfevuffkgggtugfgjgesthekredttddtjeenucfhrhhomheptehlvhgr rhhoucfjvghrrhgvrhgruceorghlvhhhvghrrhgvsegrlhhvhhdrnhhoqdhiphdrohhrgh eqnecuggftrfgrthhtvghrnhepvdektdffudfftdffffehfffhjeejhffgieeuueekjeek fffgudffhfduffffueevnecuffhomhgrihhnpegvnhhtvghrphhrihhsvggusgdrtghomh enucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrlhhv hhgvrhhrvgesrghlvhhhrdhnohdqihhprdhorhhg X-ME-Proxy: Feedback-ID: ia2694551:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 30 Aug 2022 05:06:21 -0400 (EDT) Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000) id 109B8378; Tue, 30 Aug 2022 11:06:34 +0200 (CEST) Date: Tue, 30 Aug 2022 11:06:34 +0200 From: Alvaro Herrera To: hubert depesz lubaczewski Cc: PostgreSQL mailing lists Subject: Re: pg_restore deadlocks with itself Message-ID: <20220830090634.patldggt4zddwgu5@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20220825124411.GA8257@depesz.com> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 2022-Aug-25, hubert depesz lubaczewski wrote: > Specifically, command to run it is: > sudo -u postgres pg_restore -j 64 -d database -L /tmp/schema-post-data.nopkey.list /tmp/schema-post-data.dump > 2022-08-24 20:01:04.466 UTC,"postgres","database",3343477,"[local]",630624ad.330475,42,"ALTER TABLE waiting",2022-08-24 13:16:29 UTC,21/1932,0,LOG,00000,"process 3343477 detected deadlock while waiting for ShareRowExclusiveLock on relation 742617610 of database 16641 after 1000.647 ms","Process holding the lock: 3587718. Wait queue: .",,,,,"ALTER TABLE ONLY some_schema.table_a_o > ADD CONSTRAINT table_a_o_q_id_fk FOREIGN KEY (q_id) REFERENCES some_schema.table_q(id); > ",,,"pg_restore","client backend",,3355460102417501954 > > > 2022-08-24 20:01:50.291 UTC,"postgres","database",3343477,"[local]",630624ad.330475,46,"ALTER TABLE waiting",2022-08-24 13:16:29 UTC,21/1933,0,LOG,00000,"process 3343477 detected deadlock while waiting for ShareRowExclusiveLock on relation 742617610 of database 16641 after 1000.030 ms","Process holding the lock: 3587718. Wait queue: .",,,,,"ALTER TABLE ONLY some_schema.table_a > ADD CONSTRAINT fk_rails_46718e626a FOREIGN KEY (migrate_from_id) REFERENCES some_schema.table_q(id); > ",,,"pg_restore","client backend",,-2548896815899838768 > > Now, I know I can fix the situation by adding missing fkeys myself, but > I don't think pg_restore should be putting itself in deadlock. You're right, it shouldn't. Parallel restore shouldn't run DDL commands in parallel that would deadlock, but I suppose there must be holes in that. What was process 3587718 doing at the time? Some DDL in some_schema.table_q, I suspect, right? Are any of these tables partitioned? The "Wait queue: ." bit is ugly. -- Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/ "The problem with the facetime model is not just that it's demoralizing, but that the people pretending to work interrupt the ones actually working." (Paul Graham)