Date: Wed, 13 Jan 2021 18:05:37 -0300
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: James Coleman <jtc331@gmail.com>
Cc: Michael Paquier <michael@paquier.xyz>,
	David Johnston <david.g.johnston@gmail.com>,
	PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>,
	Andres Freund <andres@anarazel.de>
Subject: Re: [DOC] Document concurrent index builds waiting on each other
Message-ID: <20210113210537.GA15374@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
 <CAAaqYe-0xO2HbkyHeMYikkArkWtQCidb-5F-cAyrYPk_DkUBZQ@mail.gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Precedence: bulk

On 2021-Jan-13, James Coleman wrote:

> On Wed, Jan 13, 2021 at 12:33 PM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:

> > This is true.  So I propose
> >
> >     Like any long-running transaction, <command>REINDEX</command> can
> >     affect which tuples can be removed by concurrent <command>VACUUM</command>
> >     on any table.
> 
> That sounds good to me.

Great, pushed with one more wording tweak: "REINDEX on any table can
affect ... on any other table".  To pg12 and up.

I wondered about noting whether only processes in the current database
are affected, but then I noticed that the current code since commit
dc7420c2c927 uses a completely different algorithm than what we had with
GetOldestXmin() and does not consider database boundaries at all.
This doesn't sound great to me, since a misbehaved database can now
affect others ...  Maybe I misunderstand that code.

-- 
Álvaro Herrera                            39°49'30"S 73°17'W
"This is what I like so much about PostgreSQL.  Most of the surprises
are of the "oh wow!  That's cool" Not the "oh shit!" kind.  :)"
Scott Marlowe, http://archives.postgresql.org/pgsql-admin/2008-10/msg00152.php