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 1oQWn9-0002RN-VE for pgsql-hackers@arkaria.postgresql.org; Tue, 23 Aug 2022 16:30:16 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1oQWn8-0004j2-RC for pgsql-hackers@arkaria.postgresql.org; Tue, 23 Aug 2022 16:30:14 +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 1oQWn7-0004is-Pw for pgsql-hackers@lists.postgresql.org; Tue, 23 Aug 2022 16:30:14 +0000 Received: from out4-smtp.messagingengine.com ([66.111.4.28]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oQWn3-0002BR-VC for pgsql-hackers@postgresql.org; Tue, 23 Aug 2022 16:30:13 +0000 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 672715C01A7; Tue, 23 Aug 2022 12:30:05 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Tue, 23 Aug 2022 12:30:05 -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=1661272205; x=1661358605; bh=w NeWMlMUbkbJSrksnwzZUYDdmr/xhhXjYRVUHpRt91g=; b=pgP+iyP9GQKTrTX1A kTjt4TzVLsVz2gMbsEGqYFWOWO2giPOe/vioCTJYcxT+83Bfhyr0KI9sfgi0FTtO IsMOFfvlx9sK/79VvqSOxUo55ssDtCiWDCO4m6F9m/unmnGZPqzehW7KHN4SFze4 WVOF+nQxM9BKB9qdDU+E28P7HUONAXjWskPQmfwAqcLIYh/IGCOylLQT33ZkzHyG e2EYRVglDGyvGC7/ws3kRM0bauh1SOytBAZFFxHspjo2HXOXY9qEAxQiW59cUi7i y1igeOqm02j3fPghsflvva0+MEpTcDuZ4xGvIcqyAPk7YOYEp41AiSl+8s9KLAlg I4dQQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrvdeiledguddtvdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepfffhvfevuffkgggtugfgjgesmh ekreertddtjeenucfhrhhomheptehlvhgrrhhoucfjvghrrhgvrhgruceorghlvhhhvghr rhgvsegrlhhvhhdrnhhoqdhiphdrohhrgheqnecuggftrfgrthhtvghrnhepudelkeekgf dttdettdekgfduvdeiffelteegjeeihfetheekveeftedtuddvhfeunecuffhomhgrihhn pegvnhhtvghrphhrihhsvggusgdrtghomhenucevlhhushhtvghrufhiiigvpedtnecurf grrhgrmhepmhgrihhlfhhrohhmpegrlhhvhhgvrhhrvgesrghlvhhhrdhnohdqihhprdho rhhg X-ME-Proxy: Feedback-ID: ia2694551:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 23 Aug 2022 12:30:04 -0400 (EDT) Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000) id 08D2A373; Tue, 23 Aug 2022 18:30:07 +0200 (CEST) Date: Tue, 23 Aug 2022 18:30:06 +0200 From: Alvaro Herrera To: Jehan-Guillaume de Rorthais Cc: pgsql-hackers Subject: Re: [BUG] parenting a PK constraint to a self-FK one (Was: Self FK oddity when attaching a partition) Message-ID: <20220823163006.smdpovyl4dhcakvr@alvherre.pgsql> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="w2gng3t6k2xa4xo3" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20220823170737.30d29668@karst> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --w2gng3t6k2xa4xo3 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit On 2022-Aug-23, Jehan-Guillaume de Rorthais wrote: Hi, [...] > However, it seems get_relation_idx_constraint_oid(), introduced in eb7ed3f3063, > assume there could be only ONE constraint depending to an index. But in fact, > multiple constraints can rely on the same index, eg.: the PK and a self > referencing FK. In consequence, when looking for a constraint depending on an > index for the given relation, either the FK or a PK can appears first depending > on various conditions. It is then possible to trick it make a FK constraint a > parent of a PK... Hmm, wow, that sounds extremely stupid. I think a sufficient fix might be to have get_relation_idx_constraint_oid ignore any constraints that are not unique or primary keys. I tried your scenario with the attached and it seems to work correctly. Can you confirm? (I only ran the pg_regress tests, not anything else for now.) If this is OK, we should make this API quirkiness very explicit in the comments, so the patch needs to be a few lines larger in order to be committable. Also, perhaps the check should be that contype equals either primary or unique, rather than it doesn't equal foreign. -- Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/ --w2gng3t6k2xa4xo3 Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="0001-test-fix.patch" From a39299db23f4b2495b3ba10e7adb1121f0271694 Mon Sep 17 00:00:00 2001 From: Alvaro Herrera Date: Tue, 23 Aug 2022 18:17:24 +0200 Subject: [PATCH] test fix --- src/backend/catalog/pg_constraint.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/src/backend/catalog/pg_constraint.c b/src/backend/catalog/pg_constraint.c index bb65fb1e0a..71b6fb35e6 100644 --- a/src/backend/catalog/pg_constraint.c +++ b/src/backend/catalog/pg_constraint.c @@ -1011,6 +1011,14 @@ get_relation_idx_constraint_oid(Oid relationId, Oid indexId) Form_pg_constraint constrForm; constrForm = (Form_pg_constraint) GETSTRUCT(tuple); + + /* + * Foreign key constraints are ignored for these purposes, + * because ...? + */ + if (constrForm->contype == CONSTRAINT_FOREIGN) + continue; + if (constrForm->conindid == indexId) { constraintId = constrForm->oid; -- 2.30.2 --w2gng3t6k2xa4xo3--