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

Поиск
Список
Период
Сортировка
От James Coleman
Тема Re: [DOC] Document concurrent index builds waiting on each other
Дата
Msg-id CAAaqYe8SYavGdG1yKRvBEv9JV5Ls7FdFj7y6pE93+iqdj6FnHQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [DOC] Document concurrent index builds waiting on each other  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Ответы Re: [DOC] Document concurrent index builds waiting on each other  (James Coleman <jtc331@gmail.com>)
Re: [DOC] Document concurrent index builds waiting on each other  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Список pgsql-hackers
On Tue, Dec 1, 2020 at 6:51 PM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
>
> 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.

Agreed. Or, alternatively, a blurb something like "Please note how CIC
interacts with VACUUM <link>...", and then the primary language in
maintenance.sgml. That would have the benefit of maintaining the core
language in only one place.

> > > 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

Ah, yes, somehow I'd missed that that had been pushed.

James



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Peter Geoghegan
Дата:
Сообщение: Re: room for improvement in amcheck btree checking?
Следующее
От: Fujii Masao
Дата:
Сообщение: Re: Allow some recovery parameters to be changed with reload