| From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | 德哥 <digoal(at)126(dot)com>, pgsql-bugs(at)lists(dot)postgresql(dot)org |
| Subject: | Re: BUG #15169: create index CONCURRENTLY conflict with other table's COPY |
| Date: | 2018-04-24 15:29:52 |
| Message-ID: | CAKFQuwY+N5tXnhtgWR5qmZwNDBuxSL=Sopb9+NH72KfPWDz1CQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alexey Bashtanov | 2018-04-24 15:32:08 | set/reset issues in create function and set_config |
| Previous Message | Andres Freund | 2018-04-24 15:16:58 | Re: BUG #15169: create index CONCURRENTLY conflict with other table's COPY |