From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
---|---|
To: | mba(dot)ogolny(at)gmail(dot)com |
Cc: | PostgreSQL mailing lists <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: BUG #14768: CREATE INDEX CONCURRENTLY IF NOT EXISTS cancels autovacuum even if the index already exists. |
Date: | 2017-08-24 04:35:01 |
Message-ID: | CAB7nPqR2O8npYOfz_2GpcppjMW9tYDu7X9BrpoUMdZhepT7eeQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Wed, Aug 2, 2017 at 12:39 PM, <mba(dot)ogolny(at)gmail(dot)com> wrote:
> I am perfectly aware of the fact that CREATE INDEX CONCURRENTLY on a table
> cancels a running autovacuum process on that table.
> But CREATE INDEX CONCURRENTLY IF NOT EXISTS should take
> ShareUpdateExclusiveLock only after checking that the index doesn't exist.
Logically the checks in index_create could happen in DefineIndex() as
there is no if_not_exists logic for toast indexes. But do we want to
skip all the sanity checks done before that, particularly for
exclusion constraints with concurrent creation? I am less sure, and
this point deserves extra opinions as those pre-checks have value in
themselves because the query defined is incorrectly shaped, so likely
users want to know about that before being sure that the named
relation already exists or not.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2017-08-24 05:00:01 | Re: BUG #14768: CREATE INDEX CONCURRENTLY IF NOT EXISTS cancels autovacuum even if the index already exists. |
Previous Message | Masahiko Sawada | 2017-08-24 03:29:17 | Re: BUG #14788: `pg_restore -c` won't restore schema access privileges. |