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 1t8Qkm-0048ur-5s for pgsql-hackers@arkaria.postgresql.org; Tue, 05 Nov 2024 21:06:19 +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 1t8Qkj-000W5i-90 for pgsql-hackers@arkaria.postgresql.org; Tue, 05 Nov 2024 21:06:17 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1t8Qki-000W5a-Vv for pgsql-hackers@lists.postgresql.org; Tue, 05 Nov 2024 21:06:17 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1t8Qkf-000OJX-CF for pgsql-hackers@postgresql.org; Tue, 05 Nov 2024 21:06:16 +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 4A5L65tI3097659; Tue, 5 Nov 2024 16:06:05 -0500 From: Tom Lane To: Alvaro Herrera cc: Tender Wang , Alexander Lakhin , Jehan-Guillaume de Rorthais , "pgsql-hackers@postgresql.org" , Guillaume Lelarge Subject: Re: [BUG] Fix DETACH with FK pointing to a partitioned table fails In-reply-to: References: <202410280916.7zm2gv25farn@alvherre.pgsql> Comments: In-reply-to Tender Wang message dated "Mon, 28 Oct 2024 19:42:54 +0800" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3097657.1730840765.1@sss.pgh.pa.us> Date: Tue, 05 Nov 2024 16:06:05 -0500 Message-ID: <3097658.1730840765@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk I'm trying to write release notes for commits 53af9491a et al, and it seems to me that we need to explain how to get out of the mess that would be left behind by the old DETACH code. There's no hint about that in the commit message :-( Clearly, if you have now-inconsistent data, there's little help for that but to manually fix the inconsistencies. What I am worried about is how to get to a state where you have correct catalog entries for the constraint. Will ALTER TABLE DROP CONSTRAINT on the now stand-alone table work to clean out the old catalog entries for the constraint? I'm worried that it will either fail, or go through but remove triggers on the referenced table that we still need for the original partitioned table. If that doesn't work I think we had better create a recipe for manually removing the detritus. Once the old entries are gone it should be possible to do ALTER TABLE ADD CONSTRAINT (with an updated server), and that would validate your data. It's the DROP CONSTRAINT part that worries me. regards, tom lane