Re: [DOC] Document concurrent index builds waiting on each other
Alvaro Herrera <alvherre@alvh.no-ip.org>
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>
Date: 2020-12-01T23:51:42Z
Lists: pgsql-hackers
On 2020-Nov-30, James Coleman wrote:
> On Mon, Nov 30, 2020 at 4:53 PM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
> >
> > On 2020-Sep-30, Michael Paquier wrote:
> > Yeah, I think it might be more sensible to document this in
> > maintenance.sgml, as part of the paragraph that discusses removing
> > tuples "to save space". But making it inline with the rest of the flow,
> > it seems to distract from higher-level considerations, so I suggest to
> > make it a footnote instead.
>
> I have mixed feelings about wholesale moving it; users aren't likely
> to read the vacuum doc when considering how running CIC might impact
> their system, though I do understand why it otherwise fits there.
Makes sense. ISTM that if we want to have a cautionary blurb CIC docs,
it should go in REINDEX CONCURRENTLY as well.
> > I'm not sure on the wording to use; what about this?
>
> The wording seems fine to me.
Great, thanks.
> This is a replacement for what was 0002 earlier? And 0001 from earlier
> still seems to be a useful standalone patch?
0001 is the one that I got pushed yesterday, I think -- correct?
src/tools/git_changelog says:
Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
Branch: master [58ebe967f] 2020-11-30 18:24:55 -0300
Branch: REL_13_STABLE [3fe0e7c3f] 2020-11-30 18:24:55 -0300
Branch: REL_12_STABLE [b2603f16a] 2020-11-30 18:24:55 -0300
Branch: REL_11_STABLE [ed9c9b033] 2020-11-30 18:24:55 -0300
Branch: REL_10_STABLE [d3bd36a63] 2020-11-30 18:24:55 -0300
Branch: REL9_6_STABLE [b3d33bf59] 2020-11-30 18:24:55 -0300
Branch: REL9_5_STABLE [968a537b4] 2020-11-30 18:24:55 -0300
Document concurrent indexes waiting on each other
Because regular CREATE INDEX commands are independent, and there's no
logical data dependency, it's not immediately obvious that transactions
held by concurrent index builds on one table will block the second phase
of concurrent index creation on an unrelated table, so document this
caveat.
Backpatch this all the way back. In branch master, mention that only
some indexes are involved.
Author: James Coleman <jtc331@gmail.com>
Reviewed-by: David Johnston <david.g.johnston@gmail.com>
Discussion: https://postgr.es/m/CAAaqYe994=PUrn8CJZ4UEo_S-FfRr_3ogERyhtdgHAb2WG_Ufg@mail.gmail.com
Commits
-
Call out vacuum considerations in create index docs
- c285a244f6d3 13.2 landed
- 93c39f987e9c 14.0 landed
- 259b21233032 12.6 landed
-
Document concurrent indexes waiting on each other
- ed9c9b033546 11.11 landed
- d3bd36a63d69 10.16 landed
- b3d33bf598dd 9.6.21 landed
- b2603f16ad75 12.6 landed
- 968a537b432e 9.5.25 landed
- 58ebe967f8a1 14.0 landed
- 3fe0e7c3fa27 13.2 landed
-
snapshot scalability: Don't compute global horizons while building snapshots.
- dc7420c2c927 14.0 cited
-
Remove PROC_IN_ANALYZE and derived flags
- cea3d5589865 14.0 landed
-
Improve performance of get_actual_variable_range with recently-dead tuples.
- 3ca930fc39cc 11.0 cited