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 1l4sT4-0005or-DL for pgsql-hackers@arkaria.postgresql.org; Wed, 27 Jan 2021 21:35:14 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1l4sT3-0000fC-3n for pgsql-hackers@arkaria.postgresql.org; Wed, 27 Jan 2021 21:35:13 +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 1l4sT2-0000f2-PR for pgsql-hackers@lists.postgresql.org; Wed, 27 Jan 2021 21:35:12 +0000 Received: from mail-io1-xd35.google.com ([2607:f8b0:4864:20::d35]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1l4sSx-0003az-6g for pgsql-hackers@lists.postgresql.org; Wed, 27 Jan 2021 21:35:11 +0000 Received: by mail-io1-xd35.google.com with SMTP id e22so3422717iog.6 for ; Wed, 27 Jan 2021 13:35:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telsasoft-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=y09EJM76pXrvZz/VOfbzH0O9q1lX8K/PvPmMO/UWO3Y=; b=c1qPPokhe1rxGGXupZDBnvZjZIgjNmIr4QCNR5hhdqQ1zoaIIiFKtxQl4TjGCP8Clp tK3JQ79f47EZg1jOF02Y7l0+sis0zDfBzBLJJmJqxScYufi9JnNdnD62ABxsS+CVB+Ps 80ri/XVitNy+7dFhWFPGRH8p4sAWo9A+zXpP2uvktcecRuW5OYD+LoxqlyI9JvC84x5y g7Mpne5Vt5aTbF8M1y53kzSx/n69PJwefKHeFBdJ3h7N7n37arPzWI+GNYbv3JevNTAR P2uTGPdS/iyWI/xwnWPHWHW1SPskQyRE+45/Uw/a0b+TBRon7Q8G0AtZsxW3goxr6WIh QwlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=y09EJM76pXrvZz/VOfbzH0O9q1lX8K/PvPmMO/UWO3Y=; b=f5JcvhRu/7GIX3K2K9VTIZqCJ4bnppDC/nldnuLwC/raQHPqCmnnmn23aY3wvf2l4u +F6uisSsy+DqHPQIBXTPZhXAKLAY1rpQIgF31wcBOAlVzPWdWPnZtcJDS5S/f/oLdBjI Si1jPbOOES5MEafKYYxvF1RJsiUnOkwzV3zLdjO8MTqPUq+znKVj49YXa6cA/mvJ30eV aY0JduCGqoBPPp2m/flVZ7qgS76Ue7n17J6ARi2tenhBhpwJEQpelSF+Qel0K/GconMP WD9EnaQpHCM1WkT1SCIA93NIk1B3DspV65gistg2NpK6vT4yL4H6felQdCi80XpsSnqk R6xA== X-Gm-Message-State: AOAM532Z33ZgBibuQlUQUqmtSj0BMonNK3TpnUKua/0TexnLjgd7wiEE w2bznEAqJSR/yZQIdFLzRGzjaw== X-Google-Smtp-Source: ABdhPJyKMPuJlUI9trv4H758rboQQNCn7tQvLTB8iigp7aTZq8ND6cgXwomNHu72aYjLfDt3BnMUeA== X-Received: by 2002:a5e:da01:: with SMTP id x1mr9189185ioj.100.1611783306074; Wed, 27 Jan 2021 13:35:06 -0800 (PST) Received: from pryzbyj.telsasoft (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id k11sm1601551ilo.8.2021.01.27.13.35.04 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 27 Jan 2021 13:35:05 -0800 (PST) Received: by pryzbyj.telsasoft (Postfix, from userid 1000) id 8AD09800A27; Wed, 27 Jan 2021 15:35:03 -0600 (CST) Date: Wed, 27 Jan 2021 15:35:03 -0600 From: Justin Pryzby To: Alexey Kondratov Cc: Michael Paquier , Alvaro Herrera , Peter Eisentraut , 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: <20210127213503.GX30745@telsasoft.com> References: <20210121212651.GY8560@telsasoft.com> <944df7cc452fe0c34cf7820da4588d05@postgrespro.ru> <690fa051803c071d213b0d07b5aa9f55@postgrespro.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Thanks for updating the patch. I have just a couple comments on the new (and old) language. On Thu, Jan 28, 2021 at 12:19:06AM +0300, Alexey Kondratov wrote: > Also added tests for ACL checks, relfilenode changes. Added ACL recheck for > multi-transactional case. Added info about TOAST index reindexing. Changed > some comments. > + Specifies that indexes will be rebuilt on a new tablespace. > + Cannot be used with "mapped" and system (unless allow_system_table_mods say mapped *or* system relations Or maybe: mapped or (unless >allow_system_table_mods<) system relations. > + is set to TRUE) relations. If SCHEMA, > + DATABASE or SYSTEM are specified, > + then all "mapped" and system relations will be skipped and a single > + WARNING will be generated. Indexes on TOAST tables > + are reindexed, but not moved the new tablespace. moved *to* the new tablespace. I don't know if that needs to be said at all. We talked about it a lot to arrive at the current behavior, but I think that's only due to the difficulty of correcting the initial mistake. > + /* > + * Set the new tablespace for the relation. Do that only in the > + * case where the reindex caller wishes to enforce a new tablespace. I'd say just "/* Set new tablespace, if requested */ You wrote something similar in an earlier revision of your refactoring patch. > + * Mark the relation as ready to be dropped at transaction commit, > + * before making visible the new tablespace change so as this won't > + * miss things. This comment is vague. I think Michael first wrote this comment about a year ago. Does it mean "so the new tablespace won't be missed" ? Missed by what ? -- Justin