| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | James Coleman <jtc331(at)gmail(dot)com> |
| Cc: | David Johnston <david(dot)g(dot)johnston(at)gmail(dot)com>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Andres Freund <andres(at)anarazel(dot)de>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
| Subject: | Re: [DOC] Document concurrent index builds waiting on each other |
| Date: | 2020-09-30 09:10:10 |
| Message-ID: | 20200930091010.GU1996@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Sep 08, 2020 at 01:25:21PM -0400, James Coleman wrote:
> Álvaro's patch confused the current state of this thread, so I'm
> reattaching (rebased) v2 as v3.
+ <para>
+ <command>CREATE INDEX</command> (including the <literal>CONCURRENTLY</literal>
+ option) commands are included when <command>VACUUM</command> calculates what
+ dead tuples are safe to remove even on tables other than the one being indexed.
+ </para>
FWIW, this is true as well for REINDEX CONCURRENTLY because both use
the same code paths for index builds and validation, with basically
the same waiting phases. But is CREATE INDEX the correct place for
that? Wouldn't it be better to tell about such things on the VACUUM
doc?
0001 sounds fine to me.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amit Kapila | 2020-09-30 09:10:41 | Re: Resetting spilled txn statistics in pg_stat_replication |
| Previous Message | Amit Kapila | 2020-09-30 09:06:24 | Re: [HACKERS] logical decoding of two-phase transactions |