Неудачный CREATE INDEX CONCURRENTLY может оставить след в базе — 16 июля 2026 г. в 10:50:01.400
Неудачный CREATE INDEX CONCURRENTLY может оставить след в базе Фрагмент миграции: CREATE INDEX CONCURRENTLY ... Миграция упала по таймауту. Кажется, что индекс просто не создался. Но после concurrent build нужно проверить состояние в PostgreSQL. В каталогах может остаться индекс с признаком: indisvalid = false Такой индекс нельзя считать рабочим. Он может быть неполным и не использоваться для запросов как обычный валидный индекс. При этом он не обязательно безвреден: может создавать overhead при изменениях данных. Что проверить после сбоя: — остался ли индекс в каталогах; — к какой таблице он относится; — зачем он создавался; — unique это индекс или нет; — нет ли связи с constraint или следующим шагом миграции; — нужно ли его удалить, пересоздать или восстановить; — безопасно ли делать это сейчас с учётом нагрузки и блокировок. Типичная ошибка — забыть про индекс после падения миграции. Но неудачный concurrent index — это не всегда «ничего не произошло». Вывод: indisvalid = false — повод не паниковать и не нажимать автоматическое удаление, а разобрать состояние индекса и выбрать безопасное действие. Сохраните проверку для миграций: неудачный concurrent index — это не всегда «ничего не произошло». #УЦФОРС #PostgreSQL #DevOps #МиграцииБД #DBA