Re: [BUGS] BUG #14768: CREATE INDEX CONCURRENTLY IF NOT EXISTScancels autovacuum even if the index already exists.
От | Michael Paquier |
---|---|
Тема | Re: [BUGS] BUG #14768: CREATE INDEX CONCURRENTLY IF NOT EXISTScancels autovacuum even if the index already exists. |
Дата | |
Msg-id | CAB7nPqR2O8npYOfz_2GpcppjMW9tYDu7X9BrpoUMdZhepT7eeQ@mail.gmail.com обсуждение исходный текст |
Ответ на | [BUGS] BUG #14768: CREATE INDEX CONCURRENTLY IF NOT EXISTS cancelsautovacuum even if the index already exists. (mba.ogolny@gmail.com) |
Ответы |
Re: [BUGS] BUG #14768: CREATE INDEX CONCURRENTLY IF NOT EXISTS cancels autovacuum even if the index already exists.
|
Список | pgsql-bugs |
On Wed, Aug 2, 2017 at 12:39 PM, <mba.ogolny@gmail.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 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
В списке pgsql-bugs по дате отправления: