Re: To create or not to create that index
| От | David G. Johnston |
|---|---|
| Тема | Re: To create or not to create that index |
| Дата | |
| Msg-id | CAKFQuwbtRgufOWG1jUuG+DJqiVs1=3g6e0Kk2shZ8xqzQaaY4A@mail.gmail.com обсуждение исходный текст |
| Ответ на | To create or not to create that index (Stefan Knecht <knecht.stefan@gmail.com>) |
| Ответы |
Re: To create or not to create that index
|
| Список | pgsql-general |
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 по дате отправления: