Horton

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

James Coleman <jtc331@gmail.com>

View thread View on postgr.es
From: James Coleman <jtc331@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Alvaro Herrera <alvherre@alvh.no-ip.org>, 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-13T22:52:16Z
Lists: pgsql-hackers 
On Wed, Jan 13, 2021 at 5:00 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> James Coleman <jtc331@gmail.com> writes:
> > On Wed, Jan 13, 2021 at 4:29 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >> but the antecedent of "a table" is a bit unclear; people might
> >> wonder if it means the table being reindexed.
>
> > It does mean the table being reindexed; the last phrase says "any
> > table" meaning "any other table".
>
> [ raised eyebrow ]  Surely REINDEX and VACUUM can't run on the same
> table at the same time.

+ Like any long-running transaction, <command>CREATE INDEX</command> on a
+ table can affect which tuples can be removed by concurrent
+ <command>VACUUM</command> on any other table.

The "on a table" is the table on which the REINDEX/CREATE INDEX is
occurring. The "any other table" is where VACUUM might run.

James

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.