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 1lO2TW-00022s-8Q for pgsql-hackers@arkaria.postgresql.org; Sun, 21 Mar 2021 18:06:54 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1lO2TV-00078m-6R for pgsql-hackers@arkaria.postgresql.org; Sun, 21 Mar 2021 18:06:53 +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 1lO2TU-00078f-W6 for pgsql-hackers@lists.postgresql.org; Sun, 21 Mar 2021 18:06:52 +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 1lO2TT-0007bj-1z for pgsql-hackers@lists.postgresql.org; Sun, 21 Mar 2021 18:06:52 +0000 Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 6FDF013B6; Sun, 21 Mar 2021 14:06:49 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Sun, 21 Mar 2021 14:06:49 -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=wz9lOOHuBD7UYKTQvTZZ0ojG6NGOE3lnAtYOZekBZLg=; b=iHoU8XCa /j0c7tC2+QWaxeNoWSfVEkKGXpNtQkQLV+FzYOBgTdSw9REA22T2ICZNaNliGIxf QHGEKF5Gvv21E1q1I1Z5e+vVfiZgnT3CMmk+QYQLIUCNYHoQ0aVWBfSNoQoShjIb ac4nJlI/aF1V8VLkNDwtbScEPWo5Y6250L/4CN6bsaWid0ZM+q9nJYG1dLr531LP Gg4tSMe0I1C8BM//XhCFIoc7TA//Uvx7ZrTDejLGL5GyPdSnpTtJngZLk097jHI1 WmTbmKmY9dmi10oibwK22fCts5YjvdUeBbyZtoyfHzUb9KFW2P0+GisTbObW1T38 V0fW1aBybpsgUw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrudegvddguddtlecutefuodetggdotefrod 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 4969224020A; Sun, 21 Mar 2021 14:06:48 -0400 (EDT) Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000) id D75302A0FD5; Sun, 21 Mar 2021 15:06:45 -0300 (-03) Date: Sun, 21 Mar 2021 15:06:45 -0300 From: Alvaro Herrera To: Justin Pryzby Cc: Amit Langote , pgsql-hackers@lists.postgresql.org Subject: Re: ALTER TABLE .. DETACH PARTITION CONCURRENTLY Message-ID: <20210321180645.GA2437@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20210319135737.GA28771@alvherre.pgsql> 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-19, Alvaro Herrera wrote: > diff --git a/src/backend/utils/cache/partcache.c b/src/backend/utils/cache/partcache.c > index 0fe4f55b04..6dfa3fb4a8 100644 > --- a/src/backend/utils/cache/partcache.c > +++ b/src/backend/utils/cache/partcache.c > @@ -352,16 +352,9 @@ generate_partition_qual(Relation rel) > return copyObject(rel->rd_partcheck); > > /* > - * Obtain parent relid; if it's invalid, then the partition is being > - * detached. The constraint is NIL in that case, and let's cache that. > + * Obtain parent relid. XXX explain why we need this > */ > - parentrelid = get_partition_parent(RelationGetRelid(rel)); > - if (parentrelid == InvalidOid) > - { > - rel->rd_partcheckvalid = true; > - rel->rd_partcheck = NIL; > - return NIL; > - } > + parentrelid = get_partition_parent(RelationGetRelid(rel), true); One thing that makes me uneasy about this, is that I don't understand how does this happen with your test of two psqls doing attach/detach. (It is necessary for the case when the waiting concurrent detach is canceled, and so this fix is necessary anyway). In your test, no waiting transaction is ever cancelled; so what is the period during which the relation is not locked that causes this code to be hit? I fear that there's a bug in the lock protocol somewhere. -- Álvaro Herrera Valdivia, Chile "In Europe they call me Niklaus Wirth; in the US they call me Nickel's worth. That's because in Europe they call me by name, and in the US by value!"