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 1nVzof-0002DS-M7 for pgsql-hackers@arkaria.postgresql.org; Sun, 20 Mar 2022 17:58:09 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nVzoe-0002vy-Hi for pgsql-hackers@arkaria.postgresql.org; Sun, 20 Mar 2022 17:58:08 +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 1nVzoe-0002vp-8w for pgsql-hackers@lists.postgresql.org; Sun, 20 Mar 2022 17:58:08 +0000 Received: from wnew2-smtp.messagingengine.com ([64.147.123.27]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nVzob-00060X-To for pgsql-hackers@postgresql.org; Sun, 20 Mar 2022 17:58:07 +0000 Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailnew.west.internal (Postfix) with ESMTP id 7EF2C2B00240; Sun, 20 Mar 2022 13:58:01 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Sun, 20 Mar 2022 13:58:02 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date: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= fm3; bh=Je6BBwWAVbI8CTXaFuQ3rjTIPA7OxSWZdq2jT04DokQ=; b=YBhOPEE4 Etq96ZSFXOOxmob/UmH1WlvCKYUXaUBEHp/nOhzfIMNNv4nYyp9499uaQeLTDYJN AxRruEdk0cqvjGlqjKegZ44NKZaubK1pdTtzpzXEpHO8hw4iOmBws3Gxjg+NvTbF p2DVVeunjaAwt3+/cL4ihWRNqTh9B/79e+66Zfzjt/5/ruSvdDxRVVV32nB8pW/l 4uQ8+AQL/ttlsmvcraZTvk4miUskSoO/XqsNCHF779cL05Bhy2WWc71I2bdzssV2 ghdhYuUQfnPSxzzvl++lrDZdjp7yhOTjjZe4boLThnZiGHogrTo6XCKOOCwCOd58 Z01k+D3I96ujrA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrudeguddguddtjecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enogfvvgigthfqnhhlhidqqdfuphgrmhgsohhtqdgkgedvvddqjeduqdgsihhsucdlfedt tddmnecujfgurhepfffhvffukfggtggugfgjsehtkeertddttdejnecuhfhrohhmpeetlh hvrghrohcujfgvrhhrvghrrgcuoegrlhhvhhgvrhhrvgesrghlvhhhrdhnohdqihhprdho rhhgqeenucggtffrrghtthgvrhhnpedujeevjeffjeevuddutedvkeeiueeitddvieelfe ekveejudefgeeuvdejhfeuleenucffohhmrghinhepvghnthgvrhhprhhishgvuggsrdgt ohhmnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprg hlvhhhvghrrhgvsegrlhhvhhdrnhhoqdhiphdrohhrgh X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun, 20 Mar 2022 13:58:00 -0400 (EDT) Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000) id 5B58A2A0665; Sun, 20 Mar 2022 14:58:07 -0300 (-03) Date: Sun, 20 Mar 2022 18:58:07 +0100 From: Alvaro Herrera To: Amit Langote Cc: Zhihong Yu , Tom Lane , Andrew Dunstan , Ibrar Ahmed , Arne Roland , "David G. Johnston" , Masahiko Sawada , Peter Eisentraut , PostgreSQL-development , Rahila Syed , Tomas Vondra Subject: Re: a misbehavior of partition row movement (?) Message-ID: <202203201758.kzmjeptr2c5f@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 2022-Mar-20, Amit Langote wrote: > On Sun, Mar 20, 2022 at 5:13 AM Alvaro Herrera wrote: > > On 2022-Mar-18, Zhihong Yu wrote: > > > + if (!partRel->rd_rel->relispartition) > > > + elog(ERROR, "cannot find ancestors of a non-partition result > > > relation"); > > > > > > It would be better to include the relation name in the error message. > > > > I don't think it matters. We don't really expect to hit this. > > I tend to think maybe showing at least the OID in the error message > doesn't hurt, but maybe we don't need to. Since we don't even know of a situation in which this error message would be raised, I'm hardly bothered by failing to print the OID. If any users complain, we can add more detail. > I've fixed the comment as: > > - /* Ignore the root ancestor, because ...?? */ > + /* Root ancestor's triggers will be processed. */ Okay, included that. > A description of what we're looking for with this code is in the > comment above the loop: > > /* > * For any foreign keys that point directly into a non-root ancestors of > * the source partition,... > > So finding triggers in those non-root ancestors whose function is > RI_TRIGGER_PK tells us that those relations have foreign keys pointing > into it or that it is the PK table in that relationship. Other than > the comment, the code itself seems self-documenting with regard to > what's being done (given the function/macro/variable naming), so maybe > we're better off without additional commentary here. Yeah, WFM. > I've attached a delta patch on v16 for the above comment and a couple > of other changes. Merged that in, and pushed. I made a couple of wording changes in comments here and there as well. I lament the fact that this fix is not going to hit Postgres 12-14, but ratio of effort to reward seems a bit too high. I think we could backpatch the two involved commits if someone is motivated enough to verify everything and come up with solutions for the necessary ABI changes. Thank you, Amit, for your perseverance in getting this bug fixed! -- Álvaro Herrera 39°49'30"S 73°17'W — https://www.EnterpriseDB.com/ "No hay hombre que no aspire a la plenitud, es decir, la suma de experiencias de que un hombre es capaz"