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 1lO2OE-0001tR-HL for pgsql-hackers@arkaria.postgresql.org; Sun, 21 Mar 2021 18:01:26 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1lO2OD-0003Yn-5s for pgsql-hackers@arkaria.postgresql.org; Sun, 21 Mar 2021 18:01:25 +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 1lO2OC-0003Yg-5q for pgsql-hackers@lists.postgresql.org; Sun, 21 Mar 2021 18:01:24 +0000 Received: from wout2-smtp.messagingengine.com ([64.147.123.25]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lO2O9-0007ZU-Vn for pgsql-hackers@lists.postgresql.org; Sun, 21 Mar 2021 18:01:23 +0000 Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 62C1512C6; Sun, 21 Mar 2021 14:01:19 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Sun, 21 Mar 2021 14:01:19 -0400 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= fm2; bh=+uewIo9DonVzeVV8H1HOtfKqXwCVVYR1stjPoSOJw2g=; b=gqu3bcGB 4VTBy+LucezjVAlg2SMt6+zYjIHnOaqcpWFak29EO4uWKYiFBzq4kXNP8Y8vEK6v 8qn4e/K0gkzBmco38AUcE4+Q3d/OEmtxcIquasCfkXo/CtMsp4CPsByoZ2BdCVUv vgFCPfcZdpsDGLiVAUXEEOPb4oXZmDbp2fCjf5lhD2zzeT0fElqSnsr3IK/EiweX z4kp2ZAIQq2M/pSfG5+zqa+DY0QeY1LLNroo26wZOUGlAP5UCGUCDx9zZWgT2bmb +Xs4uZ6qMPSKHZHY+CmkyErcxiaeb1der/oFExmdtJJOCwIUIowEPg/XtFTFliCI czYXHG5hfElPjg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrudegvddguddtkecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpeffhffvuffkgggtugfgjggfsehtkeertddtredunecuhfhrohhmpeetlhhv rghrohcujfgvrhhrvghrrgcuoegrlhhvhhgvrhhrvgesrghlvhhhrdhnohdqihhprdhorh hgqeenucggtffrrghtthgvrhhnpeeufffhjeeiueeuffegvddukeegledtveeivdeiueef ieeivefgteehueefteehvdenucfkphepudeltddrleehrdduledrleehnecuvehluhhsth gvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprghlvhhhvghrrhgvsegr lhhvhhdrnhhoqdhiphdrohhrgh X-ME-Proxy: Received: from perhan.alvh.no-ip.org (unknown [190.95.19.95]) by mail.messagingengine.com (Postfix) with ESMTPA id 4F8A924020A; Sun, 21 Mar 2021 14:01:18 -0400 (EDT) Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000) id B74E52A0FD5; Sun, 21 Mar 2021 15:01:15 -0300 (-03) Date: Sun, 21 Mar 2021 15:01:15 -0300 From: Alvaro Herrera To: Justin Pryzby Cc: Amit Langote , pgsql-hackers@lists.postgresql.org Subject: Re: ALTER TABLE .. DETACH PARTITION CONCURRENTLY Message-ID: <20210321180115.GA2101@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20210321175453.GB11765@telsasoft.com> User-Agent: Mutt/1.10.1 (2018-07-13) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 2021-Mar-21, Justin Pryzby wrote: > On Fri, Mar 19, 2021 at 10:57:37AM -0300, Alvaro Herrera wrote: > > > Also, it "fails to avoid" adding duplicate constraints: > > > > > > Check constraints: > > > "c" CHECK (i IS NOT NULL AND i > 1 AND i < 2) > > > "cc" CHECK (i IS NOT NULL AND i >= 1 AND i < 2) > > > "p1_check" CHECK (true) > > > "p1_i_check" CHECK (i IS NOT NULL AND i >= 1 AND i < 2) > > > > Do you mean the "cc" and "p1_i_check" one? I mean, if you already have > > No, I started with c and cc, and it added the broken constraint p1_check (which > you say you've fixed) and the redundant constraint p1_i_check. I guess that's > what you meant. Yes, that's what I meant. > > a constraint in the partition that duplicates the partition constraint, > > then during attach we still create our new constraint? I guess a > > solution to this would be to scan all constraints and see if any equals > > the expression that the new one would have. Sounds easy enough now that > > write it out loud. > > But it looks like DetachAddConstraintIfNeeded already intended to do that: > > + if (equal(constraintExpr, thisconstr)) > + return; Hah, so I had already done it, but forgot. > Actually, it appears your latest notpatch resolves both these issues. Great. > But note that it doesn't check if an existing constraint "implies" the new > constraint - maybe it should. Hm, I'm not sure I want to do that, because that means that if I later have to attach the partition again with the same partition bounds, then I might have to incur a scan to recheck the constraint. I think we want to make the new constraint be as tight as possible ... -- Álvaro Herrera 39°49'30"S 73°17'W