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 1kzPhl-000683-4z for pgsql-hackers@arkaria.postgresql.org; Tue, 12 Jan 2021 19:51:49 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1kzPhk-0004HU-2Z for pgsql-hackers@arkaria.postgresql.org; Tue, 12 Jan 2021 19:51:48 +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 1kzPhj-0004HN-SE for pgsql-hackers@lists.postgresql.org; Tue, 12 Jan 2021 19:51:47 +0000 Received: from out2-smtp.messagingengine.com ([66.111.4.26]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kzPhh-0006tM-Fp for pgsql-hackers@lists.postgresql.org; Tue, 12 Jan 2021 19:51:47 +0000 Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 3AE595C01EE; Tue, 12 Jan 2021 14:51:42 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Tue, 12 Jan 2021 14:51:42 -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=TPf0oBIADpBNiIIHXW+V9JQsiXMsXLbFpaP4JSMurHA=; b=R2+uIQqI 1C495va3lj4FLp5AKoMth9lmFocyRc6gNwiSpPfJHwI98/UzU99Syw6Cjmck2koJ WFchnkcXKshw0wF4Qw1Fxf5N/q1fckgGQAjqtW1egFU7u57/B3c7CCSgwLRdo7QU gQbwwW+aQygJ11kgqdbursRsdpf5GwviMk3fQRZjgdd/YdSuYG8j6Nn6HphU7JOS zTkvpARAEh6IRR8UTVM6k+BGwJSMLc1VokDPkINj3sTIJeIppJBTKKHN7dBCYrCg 2w56d8vFj8S52ipbd1zrM9T0makslOPzjFo0sSRsYjZgPFIFHmzONdWehlkV78ES EYMVsth5Z8KVAQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedukedrtddtgdelkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpeffhffvuffkgggtugfgjggfsehmkeerredtredunecuhfhrohhmpeetlhhvrghr ohcujfgvrhhrvghrrgcuoegrlhhvhhgvrhhrvgesrghlvhhhrdhnohdqihhprdhorhhgqe enucggtffrrghtthgvrhhnpefhfeegleekgfejueehgfefveelfeetvdehffdtueetgffh kefhudehffekudetkeenucfkphepudeltddrleehrdduledrudejjeenucevlhhushhtvg 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 7CC21108005F; Tue, 12 Jan 2021 14:51:41 -0500 (EST) Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000) id 2B0052A0FBF; Tue, 12 Jan 2021 16:51:39 -0300 (-03) Date: Tue, 12 Jan 2021 16:51:39 -0300 From: Alvaro Herrera To: James Coleman Cc: Michael Paquier , David Johnston , PostgreSQL Developers , Andres Freund Subject: Re: [DOC] Document concurrent index builds waiting on each other Message-ID: <20210112195139.GA31932@alvherre.pgsql> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="+QahgC5+KEYLbs62" 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: Precedence: bulk --+QahgC5+KEYLbs62 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit On 2020-Dec-01, James Coleman wrote: > On Tue, Dec 1, 2020 at 6:51 PM Alvaro Herrera wrote: > > Makes sense. ISTM that if we want to have a cautionary blurb CIC docs, > > it should go in REINDEX CONCURRENTLY as well. > > Agreed. Or, alternatively, a blurb something like "Please note how CIC > interacts with VACUUM ...", and then the primary language in > maintenance.sgml. That would have the benefit of maintaining the core > language in only one place. I looked into this again, and I didn't like what I had added to maintenance.sgml at all. It seems out of place where I put it; and I couldn't find any great spots. Going back to your original proposal, what about something like this? It's just one more para in the "notes" section in CREATE INDEX and REINDEX pages, without any additions to the VACUUM pages. -- Álvaro Herrera 39°49'30"S 73°17'W --+QahgC5+KEYLbs62 Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="v6-0001-Highlight-vacuum-consideration-in-create-index-do.patch" From 8b0aa591f5d3f34ccdc2cd0fc6031dd421f229c2 Mon Sep 17 00:00:00 2001 From: Alvaro Herrera Date: Mon, 30 Nov 2020 18:50:06 -0300 Subject: [PATCH v6] Highlight vacuum consideration in create index docs Per James Coleman --- doc/src/sgml/ref/create_index.sgml | 5 +++++ doc/src/sgml/ref/reindex.sgml | 5 +++++ 2 files changed, 10 insertions(+) diff --git a/doc/src/sgml/ref/create_index.sgml b/doc/src/sgml/ref/create_index.sgml index 2054d5d943..d951f14b09 100644 --- a/doc/src/sgml/ref/create_index.sgml +++ b/doc/src/sgml/ref/create_index.sgml @@ -829,6 +829,11 @@ Indexes: to remove an index. + + Like any long-running transaction, CREATE INDEX can + affect which tuples can be removed by concurrent VACUUM. + + Prior releases of PostgreSQL also had an R-tree index method. This method has been removed because diff --git a/doc/src/sgml/ref/reindex.sgml b/doc/src/sgml/ref/reindex.sgml index 6e1cf06713..ef553f6481 100644 --- a/doc/src/sgml/ref/reindex.sgml +++ b/doc/src/sgml/ref/reindex.sgml @@ -436,6 +436,11 @@ Indexes: CONCURRENTLY cannot. + + Like any long-running transaction, REINDEX can + affect which tuples can be removed by concurrent VACUUM. + + REINDEX SYSTEM does not support CONCURRENTLY since system catalogs cannot be reindexed -- 2.20.1 --+QahgC5+KEYLbs62--