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 1krwbE-0004Hg-Hb for pgsql-hackers@arkaria.postgresql.org; Wed, 23 Dec 2020 05:22:12 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1krwbD-0008Tc-5Q for pgsql-hackers@arkaria.postgresql.org; Wed, 23 Dec 2020 05:22:11 +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 1krwbC-0008TV-Qg for pgsql-hackers@lists.postgresql.org; Wed, 23 Dec 2020 05:22:10 +0000 Received: from mail-io1-xd36.google.com ([2607:f8b0:4864:20::d36]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1krwb5-0004kp-MZ for pgsql-hackers@lists.postgresql.org; Wed, 23 Dec 2020 05:22:09 +0000 Received: by mail-io1-xd36.google.com with SMTP id r9so14059175ioo.7 for ; Tue, 22 Dec 2020 21:22:03 -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=VeLYAUemKOhSEepuS39iSfcNyL/vUXd+xVP9lt4KB7w=; b=J3krrZozDRaUyjNOgOKchGrk0I2iSpz5Qb9qMXuu1j5JlF7vfJk2xkM9wspBYaRumG X5qi4swaCU056dRYjCORrMx/d4rryErtW+8JU4iQlmZpL0S2y/HA/kIpLMrggPziF+DG YAi2yEzNCrmVtbw8sSmPahjxoPfi5Ur1Sv1JnfrUfBLmH5n0bW6yG/CcFBRzVgiSrp2F WqXhEX+ZNBUxQ2o9JqxjStCoAVQWIHRG0gxPz2d2uNmEtPAxgFLOcXsBLCXeawJpHbeU YSc3ggkwfZXQB7DKRCTfJfhDNcoO/5YFO08y0EYe5vw9OEFowYjOTe8owO+cdwUxN+NZ LAmw== 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=VeLYAUemKOhSEepuS39iSfcNyL/vUXd+xVP9lt4KB7w=; b=dqLyvJWhjmIKQTDeshz6RLfNzncHQDP8Dl+Sv6TpklSNljyee5hZuDuv5gZZd7k7gC zBNNweeOszOor1oTUZnfLqHWol14HkptY9dS/TbeftHEPc+jRgZdYcS095XMs0HXjV2N 2wlF13htADhn4i/QmEv5gt5UsM2Jg3rkMifhQPQJaRY7JzAk5r9euUvFFXKBb0KWaCbc fNTtFePIY3Y7tlDYZBVL5sYdPevrLy0PLhftkHYvuW0oAxJVun2LrrCoUhd2KIkeBP28 /UGyBpnpP2TmEdXKVeDvAYVAOAMOUBKWMHPpib8KgKErMf4AZAshCoxbdpzkKZHLkcbD NZUg== X-Gm-Message-State: AOAM532kZyBGNwydqUtgSgDZNcPA1L/5JKOazPn6RMIS7CKO8Zpg0VeN wFUZlgCiYG09+1fBYlloVLEcEg== X-Google-Smtp-Source: ABdhPJztafJuXMwwPvV8UXSi7xDQOvILRef4NEUOwn1hWnRKyRrGo1G/TUaNtFStvFxQeTEukHyxNw== X-Received: by 2002:a02:c608:: with SMTP id i8mr21702920jan.125.1608700922316; Tue, 22 Dec 2020 21:22:02 -0800 (PST) Received: from pryzbyj.telsasoft (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id p11sm15616688ilb.13.2020.12.22.21.22.01 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 22 Dec 2020 21:22:01 -0800 (PST) Received: by pryzbyj.telsasoft (Postfix, from userid 1000) id 41DA180077C; Tue, 22 Dec 2020 23:22:00 -0600 (CST) Date: Tue, 22 Dec 2020 23:22:00 -0600 From: Justin Pryzby To: Zhihong Yu Cc: Michael Paquier , Alvaro Herrera , 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: <20201223052200.GP30237@telsasoft.com> References: <7ec67c56-2377-cd05-51a0-691104404abe@enterprisedb.com> <20201216004517.GA18498@alvherre.pgsql> <20201222083204.GL30237@telsasoft.com> <20201222211537.GO30237@telsasoft.com> 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 On Tue, Dec 22, 2020 at 03:22:19PM -0800, Zhihong Yu wrote: > Justin: > For reindex_index() : > > + if (options->tablespaceOid == MyDatabaseTableSpace) > + options->tablespaceOid = InvalidOid; > ... > + oldTablespaceOid = iRel->rd_rel->reltablespace; > + if (set_tablespace && > + (options->tablespaceOid != oldTablespaceOid || > + (options->tablespaceOid == MyDatabaseTableSpace && > OidIsValid(oldTablespaceOid)))) > > I wonder why the options->tablespaceOid == MyDatabaseTableSpace clause > appears again in the second if statement. > Since the first if statement would assign InvalidOid > to options->tablespaceOid when the first if condition is satisfied. Good question. Alexey mentioned on Sept 23 that he added the first stanza. to avoid storing the DB's tablespace OID (rather than InvalidOid). I think the 2nd half of the "or" is unnecessary since that was added setting to options->tablespaceOid = InvalidOid. If requesting to move to the DB's default tablespace, it'll now hit the first part of the OR: > + (options->tablespaceOid != oldTablespaceOid || Without the first stanza setting, it would've hit the 2nd condition: > + (options->tablespaceOid == MyDatabaseTableSpace && OidIsValid(oldTablespaceOid)))) which means: "user requested to move a table to the DB's default tblspace, and it was previously on a nondefault space". So I think we can drop the 2nd half of the OR. Thanks for noticing. -- Justin