On Tue, Dec 1, 2020 at 6:51 PM Alvaro Herrera <alvhe...@alvh.no-ip.org> wrote: > > On 2020-Nov-30, James Coleman wrote: > > > On Mon, Nov 30, 2020 at 4:53 PM Alvaro Herrera <alvhe...@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 <alvhe...@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 <jtc...@gmail.com> > Reviewed-by: David Johnston <david.g.johns...@gmail.com> > Discussion: > https://postgr.es/m/CAAaqYe994=purn8cjz4ueo_s-ffrr_3ogeryhtdghab2wg_...@mail.gmail.com Ah, yes, somehow I'd missed that that had been pushed. James
