Re: To create or not to create that index
От | Stefan Knecht |
---|---|
Тема | Re: To create or not to create that index |
Дата | |
Msg-id | CAP50yQ8vkh_msm6ZKeeVvvquNOwM2M5L4fB8KQ9kKBNrWyswXg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: To create or not to create that index ("David G. Johnston" <david.g.johnston@gmail.com>) |
Ответы |
Re: To create or not to create that index
Re: To create or not to create that index |
Список | pgsql-general |
But that "invalid" index is being used by queries....
On Fri, Aug 18, 2023 at 10:41 AM David G. Johnston <david.g.johnston@gmail.com> wrote:
On Thu, Aug 17, 2023 at 8:37 PM Stefan Knecht <knecht.stefan@gmail.com> wrote:HelloWhy does this happen?profile_aggregates=> create index concurrently foo_idx on agg (status, foots, created_ts);
^CCancel request sent
ERROR: canceling statement due to user request
profile_aggregates=>
profile_aggregates=> create index concurrently foo_idx on agg (status, foots, created_ts);
ERROR: relation " foo_idx" already existsAre these operations not atomic ?No, being atomic would interfere with doing things concurrently. Per the docs:In a concurrent index build, the index is actually entered as an “invalid” index into the system catalogs in one transaction, then two table scans occur in two more transactions....If a problem arises while scanning the table, such as a deadlock or a uniqueness violation in a unique index, the CREATE INDEX command will fail but leave behind an “invalid” index."Problem" includes you forcibly killing it while it is running.David J.
В списке pgsql-general по дате отправления: