Я только что обновил сайт с 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 пропустит эти артефакты неудач.