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

On Wed, Jan 13, 2021 at 12:33 PM Alvaro Herrera  wrote:
>
> On 2021-Jan-13, James Coleman wrote:
>
> > On Wed, Jan 13, 2021 at 12:58 AM Michael Paquier  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.

Ah, right. I've mixed those up at least once on this thread already.

> > Also that it's not just the table being indexed seems fairly significant.
>
> This is true.  So I propose
>
>     Like any long-running transaction, REINDEX can
>     affect which tuples can be removed by concurrent VACUUM
>     on any table.

That sounds good to me.

James