Reconstruyendo índices inválidos

Soporte Instalación
1

Acabo de actualizar un sitio de 1,8 millones de publicaciones a la versión 2.7.0.beta2, junto con la actualización de PG10 a PG13. Vi que beta3 acaba de salir y que incluye «mejoras en el rendimiento de la migración de la base de datos», así que procedí a actualizar de nuevo.

Cuando intento ejecutar reindex concurrently, obtengo:

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

Pensaba eliminar y volver a indexar esos índices, pero no veo ningún ccnew en el código fuente actual, así que no estoy seguro de qué hacer.

2

Parece que el índice _ccnew forma parte del proceso de reindexación concurrente:

  • Se crea un nuevo índice en los catálogos que es una copia del que se está reindexando (con algunas excepciones; por ejemplo, los índices de partición no registran su dependencia de herencia al momento de la creación, sino en el momento del intercambio). Este nuevo índice temporal tiene el sufijo «_ccnew». En resumen.

¿Puedes reindexar esos índices sin la palabra clave concurrently?

O, más adelante en esa publicación:

Luego, REINDEX TABLE CONCURRENTLY omitirá los índices inválidos porque, en caso de fallos sucesivos y múltiples, el número de índices simplemente aumentaría, duplicándose en cada ejecución, lo que causaría mucha hinchazón en las operaciones de reindexación posteriores:
…
Sin embargo, es posible reindexar índices inválidos simplemente con REINDEX INDEX CONCURRENTLY:

3

_ccnew son índices que se intentó crear mediante un reindex concurrently anterior, pero no se pudo completar, generalmente porque violan una verificación de unicidad. Los intentos fallidos de reindex concurrently permanecerán allí y deben eliminarse manualmente.

La segunda vez que ejecute reindex concurrently, PostgreSQL omitirá esos artefactos de error.

4

¡Gracias, Rafael! Eso funcionó. Eliminé esos índices con drop y realicé otro reindexado concurrente sin problemas.