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 1kzni1-0007SD-18 for pgsql-hackers@arkaria.postgresql.org; Wed, 13 Jan 2021 21:29:41 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1kznhy-00009e-U3 for pgsql-hackers@arkaria.postgresql.org; Wed, 13 Jan 2021 21:29:38 +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 1kznhy-00009X-N8 for pgsql-hackers@lists.postgresql.org; Wed, 13 Jan 2021 21:29:38 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kznhw-0005p7-Pj for pgsql-hackers@lists.postgresql.org; Wed, 13 Jan 2021 21:29:38 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 10DLTVnj1337020; Wed, 13 Jan 2021 16:29:31 -0500 From: Tom Lane To: Alvaro Herrera cc: James Coleman , Michael Paquier , David Johnston , PostgreSQL Developers , Andres Freund Subject: Re: [DOC] Document concurrent index builds waiting on each other In-reply-to: <20210113211604.GA16584@alvherre.pgsql> References: <20210113211604.GA16584@alvherre.pgsql> Comments: In-reply-to Alvaro Herrera message dated "Wed, 13 Jan 2021 18:16:04 -0300" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1337018.1610573371.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Wed, 13 Jan 2021 16:29:31 -0500 Message-ID: <1337019.1610573371@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Alvaro Herrera writes: > On 2021-Jan-13, James Coleman wrote: >>>> This is true. So I propose >>>> Like any long-running transaction, REINDEX can >>>> affect which tuples can be removed by concurrent VACUUM >>>> on any table. >> Looks like what got committed is "REINDEX on a table" not "on any", >> but I'm not sure that matters too much. > Ouch. The difference seems slight enough that it doesn't matter; is it > ungrammatical? I'd personally have written "on other tables" or "on another table", or left out that clause altogether and just said "concurrent VACUUM". I'm not sure it's ungrammatical exactly, but the antecedent of "a table" is a bit unclear; people might wonder if it means the table being reindexed. regards, tom lane