Reconstruction des index invalides

Soutien Installation
1

Je viens de mettre à jour un site de 1,8 million de publications vers la version 2.7.0.beta2, ainsi que la migration de PG10 vers PG13. J’ai vu que la version beta3 venait de sortir et qu’elle incluait des « performances améliorées pour la migration de la base de données », alors j’ai immédiatement procédé à une nouvelle mise à jour.

Lorsque j’essaie d’exécuter un reindex concurrently, j’obtiens :

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

Je comptais supprimer et réindexer ces index, mais je ne vois aucun ccnew dans le code source actuel, donc je ne suis pas sûr de la marche à suivre.

2

Il semble que l’index _ccnew fasse partie du processus de réindexation concurrente :

  • Création d’un nouvel index dans les catalogues, copie de celui qui est réindexé (avec certaines exceptions, par exemple les index de partition n’enregistrent pas leur dépendance d’héritage lors de la création, mais lors de l’échange). Ce nouvel index temporaire est suffixé par « _ccnew ». Bref.

Peut-on réindexer ces index sans utiliser le mot-clé concurrently ?

Ou, plus loin dans le même article :

Ensuite, REINDEX TABLE CONCURRENTLY va sauter les index invalides, car en cas d’échecs successifs et multiples, le nombre d’index ne ferait qu’augmenter, doublant à chaque exécution, ce qui provoquerait une forte inflation lors des opérations de réindexation suivantes :
…
Il est cependant possible de réindexer des index invalides en utilisant simplement REINDEX INDEX CONCURRENTLY :

3

_ccnew sont des index qui ont tenté d’être créés par un reindex concurrently précédent mais qui n’ont pas pu l’être, généralement parce qu’ils violent une contrainte d’unicité. Les tentatives échouées de reindex concurrently resteront là et devront être supprimées manuellement.

La deuxième fois que vous exécutez reindex concurrently, PostgreSQL ignorera ces artefacts d’échec.

4

Merci Rafael ! Ça a fonctionné. J’ai supprimé ces index et effectué une nouvelle réindexation concurrente sans aucun problème.