[DOC] Document concurrent index builds waiting on each other

>
> On 2021-Jan-13, James Coleman wrote:
>
> > On Wed, Jan 13, 2021 at 12:58 AM Michael Paquier <[hidden email]> wrote:
> > >
> > > On Tue, Jan 12, 2021 at 04:51:39PM -0300, Alvaro Herrera wrote:
> > > > I looked into this again, and I didn't like what I had added to
> > > > maintenance.sgml at all.  It seems out of place where I put it; and I
> > > > couldn't find any great spots.  Going back to your original proposal,
> > > > what about something like this?  It's just one more para in the "notes"
> > > > section in CREATE INDEX and REINDEX pages, without any additions to the
> > > > VACUUM pages.
> > >
> > > +1.
> >
> > I think one more para in the notes is good. But shouldn't we still
> > clarify the issue is specific to CONCURRENTLY?
>
> How is it specific to concurrent builds?  What we're documenting here is
> the behavior of vacuum, and that one is identical in both regular builds
> and concurrent builds (since vacuum has to avoid removing rows from
> under either of them).  The only reason concurrent builds are
> interesting is because they take longer.
>
> What was specific to concurrent builds was the fact that you can't have
> more than one at a time, and that one is what was added in 58ebe967f.

>
> On 2021-Jan-13, James Coleman wrote:
>
> > On Wed, Jan 13, 2021 at 12:33 PM Alvaro Herrera <[hidden email]> wrote:
>
> > > This is true.  So I propose
> > >
> > >     Like any long-running transaction, <command>REINDEX</command> can
> > >     affect which tuples can be removed by concurrent <command>VACUUM</command>
> > >     on any table.
> >
> > That sounds good to me.
>
> Great, pushed with one more wording tweak: "REINDEX on any table can
> affect ... on any other table".  To pg12 and up.

> On Wed, Jan 13, 2021 at 4:05 PM Alvaro Herrera <[hidden email]> wrote:
> >
> > On 2021-Jan-13, James Coleman wrote:
> >
> > > On Wed, Jan 13, 2021 at 12:33 PM Alvaro Herrera <[hidden email]> wrote:
> >
> > > > This is true.  So I propose
> > > >
> > > >     Like any long-running transaction, <command>REINDEX</command> can
> > > >     affect which tuples can be removed by concurrent <command>VACUUM</command>
> > > >     on any table.
> > >
> > > That sounds good to me.
> >
> > Great, pushed with one more wording tweak: "REINDEX on any table can
> > affect ... on any other table".  To pg12 and up.
>
> Looks like what got committed is "REINDEX on a table" not "on any",
> but I'm not sure that matters too much.

>
> Alvaro Herrera <[hidden email]> writes:
> > On 2021-Jan-13, James Coleman wrote:
> >>>> This is true.  So I propose
> >>>> Like any long-running transaction, <command>REINDEX</command> can
> >>>> affect which tuples can be removed by concurrent <command>VACUUM</command>
> >>>> on any table.
>
> >> Looks like what got committed is "REINDEX on a table" not "on any",
> >> but I'm not sure that matters too much.
>
> > Ouch.  The difference seems slight enough that it doesn't matter; is it
> > ungrammatical?
>
> I'd personally have written "on other tables" or "on another table",
> or left out that clause altogether and just said "concurrent
> <command>VACUUM</command>".  I'm not sure it's ungrammatical exactly,
> but the antecedent of "a table" is a bit unclear; people might
> wonder if it means the table being reindexed.

>
> James Coleman <[hidden email]> writes:
> > On Wed, Jan 13, 2021 at 4:29 PM Tom Lane <[hidden email]> wrote:
> >> but the antecedent of "a table" is a bit unclear; people might
> >> wonder if it means the table being reindexed.
>
> > It does mean the table being reindexed; the last phrase says "any
> > table" meaning "any other table".
>
> [ raised eyebrow ]  Surely REINDEX and VACUUM can't run on the same
> table at the same time.