Re:Re: BUG #15169: create index CONCURRENTLY conflict with other table's COPY

Still not a bug. And no we can't, because concurrent session with older snapshot can subsequently use the index.

If you have a concrete improvement proposal, please start a thread in a suitable list (general or hackers).

On April 24, 2018 6:14:37 PM MDT, "德哥" <digoal(at)126(dot)com> wrote:
>
>
>but, there is no other session get any level lock with table a(creating
>index.). so if concurrenty create index with table a , 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(dot)g(dot)johnston(at)gmail(dot)com>
>写道：
>
>
>
>On Tue, Apr 24, 2018 at 8:16 AM, Andres Freund <andres(at)anarazel(dot)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 concurrent transactions from
>operating at the same time.  With concurrently those other transactions
>can continue to work and thus the concurrent indexing performed by
>CREATE INDEX cannot know it is finished while other transactions hold
>write locks on the affected table/index.  Instead it waits "to finish"
>until those transactions finish.  The concurrent index creation has
>already started and is in progress - there just isn't any communication
>to the client as to progress.
>
>
>David J.

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.