Ho appena aggiornato un sito con 1,8 milioni di post alla versione 2.7.0.beta2, insieme all’aggiornamento da PG10 a PG13. Ho notato che beta3 è appena uscito e include “miglioramenti nelle prestazioni della migrazione del database”, quindi ho proceduto con un ulteriore aggiornamento.
Quando provo a eseguire reindex concurrently, ottengo:
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
Stavo pensando di eliminare e rieseguire l’indicizzazione di quegli indici, ma non vedo alcun riferimento a ccnew nel codice sorgente attuale, quindi non sono sicuro di cosa fare.
Sembra che l’indice _ccnew faccia parte del processo di reindicizzazione concorrente:
Viene creato un nuovo indice nei cataloghi, che è una copia di quello sottoposto a reindicizzazione (con alcune eccezioni; ad esempio, gli indici di partizione non registrano la loro dipendenza di ereditarietà al momento della creazione, ma al momento dello scambio). Questo nuovo indice temporaneo è suffissato con “_ccnew”. In breve.
È possibile eseguire la reindicizzazione di questi indici senza la parola chiave concurrently?
Oppure, come riportato più avanti nello stesso articolo:
Successivamente, REINDEX TABLE CONCURRENTLY salterà gli indici non validi perché, in caso di errori successivi e multipli, il numero di indici aumenterebbe esponenzialmente, raddoppiando ad ogni esecuzione, causando notevoli problemi di bloat nelle operazioni di reindicizzazione successive:
…
Tuttavia, è possibile eseguire la reindicizzazione degli indici non validi utilizzando semplicemente REINDEX INDEX CONCURRENTLY:
_ccnew sono indici che un precedente reindex concurrently ha tentato di creare senza riuscirci, solitamente perché violavano un controllo di unicità. I tentativi falliti di reindex concurrently rimarranno lì e dovranno essere eliminati manualmente.
La seconda volta che esegui reindex concurrently, PostgreSQL ignorerà questi artefatti di errore.