Re:Re: BUG #15169: create index CONCURRENTLY conflict with othertable's COPY - Mailing list pgsql-bugs

From 德哥
Subject Re:Re: BUG #15169: create index CONCURRENTLY conflict with othertable's COPY
Date
Msg-id 15238fbb.951.162fa26ed2b.Coremail.digoal@126.com
Whole thread Raw
In response to Re: BUG #15169: create index CONCURRENTLY conflict with other table's COPY  ("David G. Johnston" <david.g.johnston@gmail.com>)
Responses Re:Re: BUG #15169: create index CONCURRENTLY conflict with other table's COPY  (Andres Freund <andres@anarazel.de>)
List pgsql-bugs

but, there is no other session get any level lock with table a(creating index.). so if concurrenty create index with
tablea , at the end of the work, we can get a lock for table a and end the creating , like pg_repack? 






在 2018-04-24 23:29:52,"David G. Johnston" <david.g.johnston@gmail.com> 写道:



On Tue, Apr 24, 2018 at 8:16 AM, Andres Freund <andres@anarazel.de> wrote:



On 2018-04-24 12:29:47 +0000, PG Bug reporting form wrote:

> table a's copy will block table b's CONCURRENTLY index creating.



Yes, concurrently waits for other sessions to complete. I don't see a

bug here?



To be more specific a create index can stop processing as soon as its done its own work because it prevented any
concurrenttransactions from operating at the same time.  With concurrently those other transactions can continue to
workand thus the concurrent indexing performed by CREATE INDEX cannot know it is finished while other transactions hold
writelocks on the affected table/index.  Instead it waits "to finish" until those transactions finish.  The concurrent
indexcreation has already started and is in progress - there just isn't any communication to the client as to progress. 


David J.



pgsql-bugs by date:

Previous
From: PG Bug reporting form
Date:
Subject: BUG #15172: Postgresql ts_headline with <-> operator does nothighlight text properly
Next
From: Andres Freund
Date:
Subject: Re:Re: BUG #15169: create index CONCURRENTLY conflict with other table's COPY