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 1lehZV-0004B8-HL for pgsql-hackers@arkaria.postgresql.org; Thu, 06 May 2021 17:13:57 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1lehZU-00061e-FQ for pgsql-hackers@arkaria.postgresql.org; Thu, 06 May 2021 17:13:56 +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 1lehZT-0005wr-G3 for pgsql-hackers@lists.postgresql.org; Thu, 06 May 2021 17:13:56 +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 1lehZR-0005XN-7D for pgsql-hackers@lists.postgresql.org; Thu, 06 May 2021 17:13:54 +0000 Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 60E8B5C00F7; Thu, 6 May 2021 13:13:51 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Thu, 06 May 2021 13:13:51 -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=8LiOmhd64dbau01Wg8jdKirbZb7yE63MDXFgSaEU+qg=; b=BHZ8YuF0 rLCaRh+2suS/Xz6vUviWiRv3haC1czqNScXuSK96UB7MrW7Gp2jeJaxgjpCVPnXd ofwOJQXnBnEVf28cuBvHvhF14Jv8e9089nWz5dsJVju+1ePC2W/6LUqTVl50yV9G pT7yf7kMNUZTNEUtz8zYtlFOjkst57mdf5ka865KKsKkEuIkbYZRHVRDWhCoGAw6 HyohIPWmfiVq/j+GKS8cHhIskT1jRUMp5u3Uz4d96vYAEOYQutWkzZfeBjyT5gei IBebFz+AfjM7mAbLU6GeoDQHvJS0I9lx5hF0rzmUZV8Fbn8rveHa51YnB2N4vsZA gUoeprQCM5PrsQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvdegtddgudduudcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpeffhffvuffkgggtugfgjggfsehtkeertddtredunecuhfhrohhmpemllhhv rghrohcujfgvrhhrvghrrgcuoegrlhhvhhgvrhhrvgesrghlvhhhrdhnohdqihhprdhorh hgqeenucggtffrrghtthgvrhhnpeetgfdvvedvleeuhedtieduuddtjefghfffudegvdek ffdvkedtkeffueeukeevfeenucfkphepudeltddrleehrdduledrleehnecuvehluhhsth gvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprghlvhhhvghrrhgvsegr lhhvhhdrnhhoqdhiphdrohhrgh X-ME-Proxy: Received: from perhan.alvh.no-ip.org (unknown [190.95.19.95]) by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 6 May 2021 13:13:50 -0400 (EDT) Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000) id 6CA6D2A0BC3; Thu, 6 May 2021 13:13:47 -0400 (-04) Date: Thu, 6 May 2021 13:13:47 -0400 From: =?iso-8859-1?Q?=C1lvaro?= Herrera To: Amit Langote Cc: Justin Pryzby , Tom Lane , "pgsql-hackers@lists.postgresql.org" Subject: Re: ALTER TABLE .. DETACH PARTITION CONCURRENTLY Message-ID: <20210506171347.GA27028@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: 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-Apr-30, Amit Langote wrote: > The case I was looking at is when a partition detach appears as > in-progress to a serializable transaction. Yeah, I was exceedingly sloppy on my reasoning about this, and you're right that that's what actually happens rather than what I said. > If the caller wants to omit detached partitions, such a partition ends > up in rd_partdesc_nodetached, with the corresponding xmin being set to > 0 due to the way find_inheritance_children_extended() sets > *detached_xmin. The next query in the transaction that wants to omit > detached partitions, seeing rd_partdesc_nodetached_xmin being invalid, > rebuilds the partdesc, again including that partition because the > snapshot wouldn't have changed, and so on until the transaction ends. > Now, this can perhaps be "fixed" by making > find_inheritance_children_extended() set the xmin outside the > snapshot-checking block, but maybe there's no need to address this on > priority. Hmm. See below. > Rather, a point that bothers me a bit is that we're including a > detached partition in the partdesc labeled "nodetached" in this > particular case. Maybe we should avoid that by considering in this > scenario that no detached partitions exist for this transactions and > so initialize rd_partdesc, instead of rd_partdesc_nodetached. That > will let us avoid the situations where the xmin is left in invalid > state. Maybe like the attached (it also fixes a couple of > typos/thinkos in the previous commit). Makes sense -- applied, thanks. > Note that we still end up in the same situation as before where each > query in the serializable transaction that sees the detach as > in-progress to have to rebuild the partition descriptor omitting the > detached partitions, even when it's clear that the detach-in-progress > partition will be included every time. Yeah, you're right that there is a performance hole in the case where a partition pending detach exists and you're using repeatable read transactions. I didn't see it as terribly critical since it's supposed to be very transient, but I may be wrong. -- Álvaro Herrera Valdivia, Chile "Hay quien adquiere la mala costumbre de ser infeliz" (M. A. Evans)