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: James Coleman <jtc331@gmail.com>
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-13T23:49:25Z
Lists: pgsql-hackers 
James Coleman <jtc331@gmail.com> writes:
> On Wed, Jan 13, 2021 at 5:00 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> [ 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.

I still think it'd be just as clear without the auxiliary clauses,
say

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

			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.