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 1n5S2i-0000P0-Cm for pgsql-hackers@arkaria.postgresql.org; Thu, 06 Jan 2022 12:38:56 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1n5S2h-0005xW-A4 for pgsql-hackers@arkaria.postgresql.org; Thu, 06 Jan 2022 12:38:55 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1n5S0U-00086e-CZ for pgsql-hackers@lists.postgresql.org; Thu, 06 Jan 2022 12:36:38 +0000 Received: from out1-smtp.messagingengine.com ([66.111.4.25]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1n5S0R-0002yn-Qi for pgsql-hackers@postgresql.org; Thu, 06 Jan 2022 12:36:37 +0000 Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id EB32F5C013E; Thu, 6 Jan 2022 07:36:34 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute6.internal (MEProxy); Thu, 06 Jan 2022 07:36:34 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:subject:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=rJQgVaGHzoE6b34wTj8vn/W0Y/dhfH6K/LI2S6sTFyY=; b=VakKiDLo E1HzXjZxzf7NlZOQyKktmenV1AwaigCjh4hsYG/v99XCF2EuS2Ezhu7TNVzbNWxS i8E8aanBcnpzGEbXP2XxL14CxcWwwBJMqvZ3YXEOFYrfxH++Sywxrjtt+1fAappF mabLDkrLNO27hpUIbQko8odpxYLGifV99HzgRwMvmpV/Bbfq/04xl6L83jJZB6G2 pOtNtMYxkq3cAWH9l5+EE7GjWpH0z2HlIVPt3w3iDWY9Mt7qZlJ58XXcerDKg7s7 HHUYn09BwyyfimwMe5zUtwVadG8O/7EY27y2wyErQU2Tz/ar6keqRR9bfEab9qzT Ie2HngEy7SoO/Q== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrudefledggeduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvffukfggtggugfgjsehtkeertddttdejnecuhfhrohhmpeetlhhvrghr ohcujfgvrhhrvghrrgcuoegrlhhvhhgvrhhrvgesrghlvhhhrdhnohdqihhprdhorhhgqe enucggtffrrghtthgvrhhnpedujeevjeffjeevuddutedvkeeiueeitddvieelfeekveej udefgeeuvdejhfeuleenucffohhmrghinhepvghnthgvrhhprhhishgvuggsrdgtohhmne cuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprghlvhhh vghrrhgvsegrlhhvhhdrnhhoqdhiphdrohhrgh X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 6 Jan 2022 07:36:34 -0500 (EST) Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000) id A38212A073A; Thu, 6 Jan 2022 09:36:31 -0300 (-03) Date: Thu, 6 Jan 2022 09:36:31 -0300 From: Alvaro Herrera To: Amit Langote Cc: 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: <202201061236.bgv32vb7xzir@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-Jan-06, Amit Langote wrote: > On Thu, Jan 6, 2022 at 7:27 AM Alvaro Herrera wrote: > > I have pushed it thinking that we would not backpatch any of this fix. > > However, after running the tests and realizing that I didn't need an > > initdb for either patch, I wonder if maybe the whole series *is* > > backpatchable. > > We do lack help from trigger.c in the v12 branch in that there's no > Trigger.tgisclone, which is used in a couple of places in the fix. I > haven't checked how big of a deal it would be to back-port > Trigger.tgisclone to v12, but maybe that's doable. Yeah, I realized afterwards that we added tgparentid in 13 only (b9b408c48), so we should only backpatch to that. > > There is one possible problem, which is that psql and pg_dump would need > > testing to verify that they work decently (i.e. no crash, no > > misbehavior) with partitioned tables created with the original code. > > I suppose you mean checking if the psql and pg_dump after applying > *0001* work sanely with partitioned tables defined without 0001? Yes. > Will test that. I looked at the backpatch at the last minute yesterday. The tablecmds.c conflict is easy to resolve, but the one in pg_dump.c is a giant conflict zone that I didn't have time to look closely :-( -- Álvaro Herrera Valdivia, Chile — https://www.EnterpriseDB.com/