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 1l0PJu-0004iX-TZ for pgsql-hackers@arkaria.postgresql.org; Fri, 15 Jan 2021 13:39:19 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1l0PJt-0002mv-QN for pgsql-hackers@arkaria.postgresql.org; Fri, 15 Jan 2021 13:39:17 +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 1l0PJs-0002mo-UE for pgsql-hackers@lists.postgresql.org; Fri, 15 Jan 2021 13:39:17 +0000 Received: from [66.111.4.27] (helo=out3-smtp.messagingengine.com) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1l0PJo-0007wf-2d for pgsql-hackers@lists.postgresql.org; Fri, 15 Jan 2021 13:39:15 +0000 Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 59C7F5C00F0; Fri, 15 Jan 2021 08:39:01 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Fri, 15 Jan 2021 08:39:01 -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=j5nJFKrEw4EIN3FK2V4jQCaN3o81A6lfPgV18CbIFzc=; b=QnS+4K3I wV4ZVg3/vOg6VilpxMlxiswrfwC4TkLrFF1oiaV/FvmIEouybxz/3DHpMM3gpsvw yfX5vcghjenW7OXmnINRfwOXXBJUzGW1UXdCswd37s5rErYToo2AukH//pilraQ+ w0ROE6d/PKpPX8NtS1auz6wXarF0nPPtCBiSkaBjIpuQ2Dlqs/SYYF//a97n2ANI u/j4sXzV5nNRRTzdh3g+YAm3/uxu83l7b5oaptAOZqCTj8qJICU3D2VZeXblSUkQ keSAO4ZYx/8qYhYFVxaMOGNhE6yTLi/QzhtZrw9oexvCDYkwL/4BZ0k/tN4txCQj WdyVpnOuuBteHg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrtddvgdeftdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpeffhffvuffkgggtugfgjggfsehtkeertddtreejnecuhfhrohhmpemllhhvrghr ohcujfgvrhhrvghrrgcuoegrlhhvhhgvrhhrvgesrghlvhhhrdhnohdqihhprdhorhhgqe enucggtffrrghtthgvrhhnpeetgeffuefhieeigeefleehudejtdffgfeugfejtdekveej uddvffffjefgveeikeenucfkphepudeltddrleehrdduledrudejjeenucevlhhushhtvg hrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrlhhvhhgvrhhrvgesrghl vhhhrdhnohdqihhprdhorhhg X-ME-Proxy: Received: from perhan.alvh.no-ip.org (unknown [190.95.19.177]) by mail.messagingengine.com (Postfix) with ESMTPA id C62A91080063; Fri, 15 Jan 2021 08:39:00 -0500 (EST) Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000) id 613BD2A0FB5; Fri, 15 Jan 2021 10:38:58 -0300 (-03) Date: Fri, 15 Jan 2021 10:38:58 -0300 From: =?iso-8859-1?Q?=C1lvaro?= Herrera To: Masahiko Sawada Cc: Hamid Akhtar , PostgreSQL Hackers Subject: Re: {CREATE INDEX, REINDEX} CONCURRENTLY improvements Message-ID: <20210115133858.GA18931@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20210112202129.GA7219@alvherre.pgsql> User-Agent: Mutt/1.10.1 (2018-07-13) X-Host-Lookup-Failed: Reverse DNS lookup failed for 66.111.4.27 (deferred) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 2021-Jan-12, Álvaro Herrera wrote: > On 2021-Jan-12, Álvaro Herrera wrote: > > > > For the 0001 patch, since ReindexIndexInfo is used only within > > > ReindexRelationConcurrently() I think it’s a function-local structure > > > type. So we can declare it within the function. What do you think? > > > > That's a good idea. Pushed with that change, thanks. > > Here's the other patch, with comments fixed per reviews, and rebased to > account for the scope change. Pushed. At the last minute I decided to back off on reverting the flag set that DefineIndex has, because there was no point in doing that. I also updated the comment in (two places of) ReindexRelationConcurrently about why we don't do it there. The previous submission had this: > + /* > + * This transaction doesn't need to set the PROC_IN_SAFE_IC flag, because > + * it only acquires an Xid to do some catalog manipulations, after the > + * wait is over. > + */ but this fails to point out that the main reason not to do it, is to avoid having to decide whether to do it or not when some indexes are safe and others aren't. So I changed to: + /* + * While we could set PROC_IN_SAFE_IC if all indexes qualified, there's no + * real need for that, because we only acquire an Xid after the wait is + * done, and that lasts for a very short period. + */ Thanks! -- Álvaro Herrera Valdivia, Chile "The eagle never lost so much time, as when he submitted to learn of the crow." (William Blake)