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 1kkFR6-0001kW-93 for pgsql-hackers@arkaria.postgresql.org; Tue, 01 Dec 2020 23:51:56 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1kkFR3-0005zb-Tg for pgsql-hackers@arkaria.postgresql.org; Tue, 01 Dec 2020 23:51:53 +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 1kkFR3-0005zU-MX for pgsql-hackers@lists.postgresql.org; Tue, 01 Dec 2020 23:51:53 +0000 Received: from out1-smtp.messagingengine.com ([66.111.4.25]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kkFQw-0003DA-Ld for pgsql-hackers@lists.postgresql.org; Tue, 01 Dec 2020 23:51:52 +0000 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 860975C00FD; Tue, 1 Dec 2020 18:51:45 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Tue, 01 Dec 2020 18:51:45 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc: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=AaBwOK0MRPsSI0Fxx NtIn0skJnw8/seI2iY4foPMoSc=; b=UrjvIumwLK6CAQJzmIzf2BSpW7+AlGOtB RsNMmdPu7cib26SX6yW25yXb12+320LNClDKuivzCj/6PhQXwaCkz7w9H6b7wK32 SHSgYVjF9RoWOgN8Pf/m4UjYot3FjLTd+9FmLclltIntGJie2AX80904r7X2OXIq YiveRQTojX9CJ7dD8mm3ekKx1aL1WMeNLE16GKip3hJPl4vmha68oRFksxSj01AF FmAlxAGXGTWcPIFT73PAXtwtp539HRos+QcO0Cu4dVutpv8ltWS2P/RW9M0la1Mh MDf97oVLqvJZP5yQvprOFUpJp66SGYsJUAXx7rdiFtwOMY2rxVz9g== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudeifedgudeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvffukfggtggujggfsehttdertddtredvnecuhfhrohhmpeetlhhvrghr ohcujfgvrhhrvghrrgcuoegrlhhvhhgvrhhrvgesrghlvhhhrdhnohdqihhprdhorhhgqe enucggtffrrghtthgvrhhnpefhleeufeejjedvvdeggeefteefgfeijeeitdeuueejtdei gfdtvdetgeegkeeuffenucffohhmrghinhepphhoshhtghhrrdgvshenucfkphepudeltd drleehrddukedrjeelnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghi lhhfrhhomheprghlvhhhvghrrhgvsegrlhhvhhdrnhhoqdhiphdrohhrgh X-ME-Proxy: Received: from perhan.alvh.no-ip.org (unknown [190.95.18.79]) by mail.messagingengine.com (Postfix) with ESMTPA id 6F4241080059; Tue, 1 Dec 2020 18:51:44 -0500 (EST) Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000) id 12BB22A0BB8; Tue, 1 Dec 2020 20:51:42 -0300 (-03) Date: Tue, 1 Dec 2020 20:51:42 -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: <20201201235142.GA22698@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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 On 2020-Nov-30, James Coleman wrote: > On Mon, Nov 30, 2020 at 4:53 PM Alvaro Herrera wrote: > > > > On 2020-Sep-30, Michael Paquier wrote: > > Yeah, I think it might be more sensible to document this in > > maintenance.sgml, as part of the paragraph that discusses removing > > tuples "to save space". But making it inline with the rest of the flow, > > it seems to distract from higher-level considerations, so I suggest to > > make it a footnote instead. > > I have mixed feelings about wholesale moving it; users aren't likely > to read the vacuum doc when considering how running CIC might impact > their system, though I do understand why it otherwise fits there. Makes sense. ISTM that if we want to have a cautionary blurb CIC docs, it should go in REINDEX CONCURRENTLY as well. > > I'm not sure on the wording to use; what about this? > > The wording seems fine to me. Great, thanks. > This is a replacement for what was 0002 earlier? And 0001 from earlier > still seems to be a useful standalone patch? 0001 is the one that I got pushed yesterday, I think -- correct? src/tools/git_changelog says: Author: Alvaro Herrera Branch: master [58ebe967f] 2020-11-30 18:24:55 -0300 Branch: REL_13_STABLE [3fe0e7c3f] 2020-11-30 18:24:55 -0300 Branch: REL_12_STABLE [b2603f16a] 2020-11-30 18:24:55 -0300 Branch: REL_11_STABLE [ed9c9b033] 2020-11-30 18:24:55 -0300 Branch: REL_10_STABLE [d3bd36a63] 2020-11-30 18:24:55 -0300 Branch: REL9_6_STABLE [b3d33bf59] 2020-11-30 18:24:55 -0300 Branch: REL9_5_STABLE [968a537b4] 2020-11-30 18:24:55 -0300 Document concurrent indexes waiting on each other Because regular CREATE INDEX commands are independent, and there's no logical data dependency, it's not immediately obvious that transactions held by concurrent index builds on one table will block the second phase of concurrent index creation on an unrelated table, so document this caveat. Backpatch this all the way back. In branch master, mention that only some indexes are involved. Author: James Coleman Reviewed-by: David Johnston Discussion: https://postgr.es/m/CAAaqYe994=PUrn8CJZ4UEo_S-FfRr_3ogERyhtdgHAb2WG_Ufg@mail.gmail.com