Horton

Re: [DOC] Document concurrent index builds waiting on each other

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: James Coleman <jtc331@gmail.com>, Michael Paquier <michael@paquier.xyz>, David Johnston <david.g.johnston@gmail.com>, PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>, Andres Freund <andres@anarazel.de>
Date: 2021-01-13T21:29:31Z
Lists: pgsql-hackers 
Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> On 2021-Jan-13, James Coleman 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.

>> 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
<command>VACUUM</command>".  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

Commits

  1. Call out vacuum considerations in create index docs

  2. Document concurrent indexes waiting on each other

  3. snapshot scalability: Don't compute global horizons while building snapshots.

  4. Remove PROC_IN_ANALYZE and derived flags

  5. Improve performance of get_actual_variable_range with recently-dead tuples.