Восстановление некорректных индексов

Я только что обновил сайт с 1,8 млн постов до версии 2.7.0.beta2, а вместе с ним и PostgreSQL с версии 10 до 13. Я заметил, что вышла версия beta3 с улучшенной производительностью миграции базы данных, поэтому сразу же обновился ещё раз.

При попытке выполнить reindex concurrently я получаю:

WARNING:  cannot reindex invalid index "public.allowed_pm_users_pkey_ccnew" concurrently, skipping
WARNING:  cannot reindex invalid index "public.index_allowed_pm_users_on_user_id_and_allowed_pm_user_id_ccnew" concurrently, skipping
WARNING:  cannot reindex invalid index "public.index_allowed_pm_users_on_allowed_pm_user_id_and_user_id_ccnew" concurrently, skipping

Я планировал удалить эти индексы и создать их заново, но в текущем исходном коде я не вижу упоминаний ccnew, поэтому не уверен, что делать.

Похоже, что индекс _ccnew является частью процесса одновременной перестройки индексов (REINDEX CONCURRENTLY):

  • Создается новый индекс в каталогах, который является копией перестраиваемого индекса (с некоторыми исключениями, например, индексы разделов не регистрируют зависимость наследования при создании, а во время замены). Этот новый временный индекс имеет суффикс «_ccnew». Коротко говоря.

Можно ли перестроить эти индексы без ключевого слова concurrently?

Или, из более поздней части той же статьи:

Затем команда REINDEX TABLE CONCURRENTLY будет пропускать недействительные индексы, потому что в случае последовательных и множественных сбоев количество индексов просто будет расти, удваиваясь при каждом запуске, что приведет к значительному раздуванию при последующих операциях перестройки индексов:

Однако возможно перестроить недействительные индексы, используя только REINDEX INDEX CONCURRENTLY:

_ccnew — это индексы, которые пытались создать с помощью предыдущей команды reindex concurrently, но не удалось, обычно из-за нарушения проверки уникальности. Неудачные попытки выполнения reindex concurrently останутся в системе и должны быть удалены вручную.

При повторном запуске reindex concurrently PostgreSQL пропустит эти артефакты неудач.

Спасибо, Рафаэль! Это сработало. Я удалил эти индексы и выполнил повторную параллельную перестройку индексов без проблем.