🛠️ CREATE INDEX CONCURRENTLY упал. Проверьте, не остался ли invalid index

Сценарий из миграции:

CREATE INDEX CONCURRENTLY ...

Команда хотела добавить индекс без остановки записи в таблицу.

Но миграция упала по таймауту.

Опасная мысль в этот момент:

раз миграция упала, значит индекс не появился

Для CREATE INDEX CONCURRENTLY это не всегда безопасный вывод.

Concurrent build проходит несколько этапов. Индекс может быть уже зарегистрирован в системных каталогах, но ещё не стать валидным для использования в запросах.

После сбоя можно обнаружить:

indisvalid = false

Это значит: индекс нельзя считать полноценным рабочим индексом.

Что важно проверить:

— есть ли в базе индекс с indisvalid = false; — к какой таблице он относится; — под какой запрос или constraint он создавался; — не является ли он unique, partial или expression index; — создаёт ли overhead при изменениях данных; — нужен ли план удаления, пересоздания или восстановления; — не скроет ли повторный запуск миграции старый invalid index.

Главное — не принимать решение автоматически.

Нельзя просто сказать:

invalid — значит удаляем

И нельзя просто сказать:

почти создался — значит оставляем

Нужно понять роль индекса и последствия действия: связь с constraint, нагрузку, блокировки и ограничения команд вроде DROP INDEX CONCURRENTLY или REINDEX CONCURRENTLY.

Практический вывод: после неудачного CREATE INDEX CONCURRENTLY добавьте в чек-лист проверку invalid indexes. Это помогает не оставить в production артефакт, который не выполняет ожидаемую роль и может мешать сопровождению.

Сохраните проверку для миграций: неудачный concurrent index — это не всегда «ничего не произошло».

🔹🔹🔹🔹