On Sat, Sep 28, 2019 at 09:54:48PM -0400, James Coleman wrote:
> On Sat, Sep 28, 2019 at 9:22 PM Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
> >
> > On 2019-Sep-28, Bruce Momjian wrote:
> >
> > > The CREATE INDEX docs already say:
> > >
> > > In a concurrent index build, the index is actually entered into
> > > the system catalogs in one transaction, then two table scans occur in
> > > two more transactions. Before each table scan, the index build must
> > > wait for existing transactions that have modified the table to terminate.
> > > After the second scan, the index build must wait for any transactions
> > > --> that have a snapshot (see <xref linkend="mvcc"/>) predating the second
> > > --> scan to terminate. Then finally the index can be marked ready for use,
> > >
> > > So, having multiple concurrent index scans is just a special case of
> > > having to "wait for any transactions that have a snapshot", no? I am
> > > not sure adding a doc mention of other index builds really is helpful.
> >
> > I always thought that create index concurrently was prevented from
> > running concurrently in a table by the ShareUpdateExclusive lock that's
> > held during the operation.
>
> You mean multiple CICs on a single table at the same time? Yes, that
> (unfortunately) isn't possible, but I'm concerned in the patch with
> the fact that CIC on table X blocks CIC on table Y.
I think any open transaction will block CIC, which is my point.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +