Acabei de atualizar um site com 1,8 milhão de posts para a versão 2.7.0.beta2, junto com a atualização do PostgreSQL 10 para o 13. Percebi que a beta3 acabou de sair e traz “melhoria no desempenho da migração do banco de dados”, então resolvi atualizar novamente.
Ao tentar executar um reindex concurrently, recebo:
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
Eu ia descartar e reindexar esses índices, mas não vejo nenhum ccnew no código-fonte atual, então não tenho certeza do que fazer.
Parece que o índice _ccnew faz parte do processo de reindexação concorrente:
Cria um novo índice nos catálogos que é uma cópia do índice sendo reindexado (com algumas exceções; por exemplo, índices de partição não têm sua dependência de herança registrada no momento da criação, mas no momento da troca). Este novo índice temporário recebe o sufixo “_ccnew”. Em resumo.
Você pode reindexar esses índices sem usar a palavra-chave concurrently?
Ou, de uma parte posterior do mesmo post:
Então, o REINDEX TABLE CONCURRENTLY pulará índices inválidos porque, em caso de falhas sucessivas e múltiplas, o número de índices aumentaria continuamente, dobrando a cada execução, causando grande inchaço nas operações de reindexação subsequentes:
…
No entanto, é possível reindexar índices inválidos usando apenas REINDEX INDEX CONCURRENTLY:
_ccnew são índices que tentaram ser criados por um reindex concurrently anterior, mas não puderam ser criados, geralmente porque violavam uma verificação de unicidade. As tentativas falhas de reindex concurrently permanecerão lá e devem ser excluídas manualmente.
Na segunda vez que você executar reindex concurrently, o PostgreSQL ignorará esses artefatos de falha.