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 по дате отправления:
Следующее
От: Fujii MasaoДата:
Сообщение: Re: Allow some recovery parameters to be changed with reload