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 1l2Fp4-0004QI-3B for pgsql-hackers@arkaria.postgresql.org; Wed, 20 Jan 2021 15:55:06 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1l2Fp3-0003ze-0N for pgsql-hackers@arkaria.postgresql.org; Wed, 20 Jan 2021 15:55:05 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1l2Fp2-0003zW-Q5 for pgsql-hackers@lists.postgresql.org; Wed, 20 Jan 2021 15:55:04 +0000 Received: from new1-smtp.messagingengine.com ([66.111.4.221]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1l2Fow-0002EM-1O for pgsql-hackers@lists.postgresql.org; Wed, 20 Jan 2021 15:55:04 +0000 Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailnew.nyi.internal (Postfix) with ESMTP id 6EA3B580591; Wed, 20 Jan 2021 10:54:55 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Wed, 20 Jan 2021 10:54:55 -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=Q23eZ3LH5o4n+hkMtLxChitdhQUFd9nrDn5bz/0zGP8=; b=hN0SeSn2 191OIiRWpQvdC6hOKVeo+icgcqkgAHaySIKWC/mbK/3Wt6NW4mPYfGUeZbS3VTM5 pg64G9ANBW9AZ9k/WBHp8Y0+WxtF9Ju5lR/rFdbMsm44F4kdKMtn0x2KzDr14Bvb +vxmiS3K5W3qecbNnAZxVr2NJonN8m1FPdetadVgk47xsIG8+7n+w+h5ncc/kyz9 OLK0lrjvJ3cCfbewE53cXKMDLEGVrfdNGBJJmEWpGB3poA2EiDntrUnxsTQ+rAd4 A5CwSojlSATsVcWGr1hSw1tt6SIeC7Vsy2V021oIGiaA4HyXUEXuqzeMVUIb7cOD ib+6dKnoel0lrQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledruddvgdekfecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpeffhffvuffkgggtugfgjggfsehtkeertddtredunecuhfhrohhmpeetlhhvrghr ohcujfgvrhhrvghrrgcuoegrlhhvhhgvrhhrvgesrghlvhhhrdhnohdqihhprdhorhhgqe enucggtffrrghtthgvrhhnpeehudelvefggeejveeigfdukeekvedttdekfeevtdfghfej veeviedtkeegtdeukeenucffohhmrghinhepthhhvghlihhnuhigrhgvvhhivgifrdgtoh hmnecukfhppeduledtrdelhedrudelrddujeejnecuvehluhhsthgvrhfuihiivgeptden ucfrrghrrghmpehmrghilhhfrhhomheprghlvhhhvghrrhgvsegrlhhvhhdrnhhoqdhiph drohhrgh X-ME-Proxy: Received: from perhan.alvh.no-ip.org (unknown [190.95.19.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 32F49240069; Wed, 20 Jan 2021 10:54:53 -0500 (EST) Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000) id CEAA02A0FBF; Wed, 20 Jan 2021 12:54:50 -0300 (-03) Date: Wed, 20 Jan 2021 12:54:50 -0300 From: Alvaro Herrera To: Michael Paquier Cc: Justin Pryzby , Peter Eisentraut , Alexey Kondratov , Masahiko Sawada , Steve Singer , pgsql-hackers@lists.postgresql.org, Robert Haas , Alexander Korotkov , Masahiko Sawada , Jose Luis Tallon Subject: Re: Allow CLUSTER, VACUUM FULL and REINDEX to change tablespace on the fly Message-ID: <20210120155450.GA9584@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20210120154707.GA9324@alvherre.pgsql> User-Agent: Mutt/1.10.1 (2018-07-13) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 2021-Jan-20, Alvaro Herrera wrote: > On 2021-Jan-20, Michael Paquier wrote: > > > +/* > > + * This is mostly duplicating ATExecSetTableSpaceNoStorage, > > + * which should maybe be factored out to a library function. > > + */ > > Wouldn't it be better to do first the refactoring of 0002 and then > > 0001 so as REINDEX can use the new routine, instead of putting that > > into a comment? > > I think merging 0001 and 0002 into a single commit is a reasonable > approach. ... except it doesn't make a lot of sense to have set_rel_tablespace in either indexcmds.c or index.c. I think tablecmds.c is a better place for it. (I would have thought catalog/storage.c, but that one's not the right abstraction level it seems.) But surely ATExecSetTableSpaceNoStorage should be using this new routine. (I first thought 0002 was doing that, since that commit is calling itself a "refactoring", but now that I look closer, it's not.) -- Álvaro Herrera 39°49'30"S 73°17'W "On the other flipper, one wrong move and we're Fatal Exceptions" (T.U.X.: Term Unit X - http://www.thelinuxreview.com/TUX/)