¡Gracias a todos aquí! Corregí la clave duplicada, eliminé los índices obsoletos y luego ejecuté
REINDEX DATABASE discourse;
VACUUM VERBOSE ANALYZE;
con éxito. El uso de la CPU ha vuelto a la normalidad. Uf.
Pregunta: ¿Por qué una base de datos no optimizada o un índice roto provocan un uso tan alto de la CPU por parte de postmaster? Solo por curiosidad.
Creo que el índice roto es una pista falsa; ciertamente no es ideal y debería corregirse.
El gran problema es que esta migración de 10 a 12 deja la base de datos con estadísticas muy deficientes, lo que genera un rendimiento pobre.
El rendimiento es malo porque el optimizador de consultas elige planes muy inadecuados para las consultas, ya que las estadísticas que tiene sobre los datos en las tablas son completamente incorrectas.
Integraremos la reconstrucción de estadísticas mediante vacuum en nuestra migración automatizada.
Gracias, @sam, por las explicaciones. Tiene sentido. Supongo que es una buena idea integrar la reconstrucción en el movimiento automatizado. ¡Gracias de nuevo por tu ayuda!