Mientras trabajaba en un contenedor local donde he importado datos de un foro SMF2 con más de 20 años de actividad, me he topado con un error crítico en Topic.reset_all_highest.
Después de importar los datos, mi base de datos muestra alrededor de 60.000 temas regulares y alrededor de 400.000 temas de mensajes privados, y las consultas en Topic.reset_all_highest causan una especie de crecimiento geométrico de las filas, con el resultado de que mi disco se queda sin espacio (con 120 GB libres para empezar).
Actualmente estoy intentando dividir las consultas en fragmentos manejables y ejecutarlas directamente en Postgres, pero eso es, por supuesto, subóptimo (y no estoy seguro de que funcione y dé resultados correctos).
He intentado ver si alguien más tenía este tipo de problema, pero no he encontrado nada, así que me pregunto si esto podría estar relacionado de alguna manera con mi propia configuración; estoy usando la última versión de Docker, para que conste.
He realizado una importación de tamaño modesto últimamente que también se está colgando aparentemente de forma indefinida en Topic.reset_all_highest y he tenido que matar la consulta en Postgres para continuar. No había tenido este problema antes y pensé que quizás era solo que mi servidor de postgres estaba sobrecargado (tiene muchos sitios conectados).
Mi siguiente paso fue moverme a otro servidor de postgres, pero aún no lo he hecho.
Después de que los dos primeros fragmentos de mi experimento de “consulta dividida” salieron bien (X e Y para temas públicos), lo intenté con el Z, y se congeló; es decir, la consulta estaba activa según la actividad de postgres, y top mostraba el proceso ejecutándose al 100%.
Así que volví a mirar el SQL y encontré el problema: ambas consultas terminan así
WHERE
topics.archetype <> 'private_message' AND
X.topic_id = topics.id AND
Y.topic_id = topics.id AND
(
topics.highest_staff_post_number <> X.highest_post_number OR
topics.highest_post_number <> Y.highest_post_number OR
topics.last_posted_at <> Y.last_posted_at OR
topics.posts_count <> Y.posts_count OR
topics.word_count <> Z.word_count
)
(la otra tiene ‘private_message’ como arquetipo, por supuesto)
Lo que significa que a la consulta le falta
Z.topic_id = topics.id - lo que causa el aumento geométrico completo.
Cambiando la cláusula WHERE de las consultas a
WHERE
topics.archetype <> 'private_message' AND
X.topic_id = topics.id AND
Y.topic_id = topics.id AND
Z.topic_id = topics.id AND
(
topics.highest_staff_post_number <> X.highest_post_number OR
topics.highest_post_number <> Y.highest_post_number OR
topics.last_posted_at <> Y.last_posted_at OR
topics.posts_count <> Y.posts_count OR
topics.word_count <> Z.word_count
)
me solucionó el problema.
¿Debería abrir un PR?
Yo pensaría que sí. Si puedes encontrar un commit que haya roto eso, sería aún más convincente.
He abierto una PR para esto, con algunas limitaciones desafortunadas (es decir, no puedo imaginar cómo probar este cambio).
Este cambio parece correcto, lo fusionaré.
(En cuanto a las pruebas, debería haber cobertura y una prueba simple sería suficiente para validarlo, solo necesitamos confirmar que no hay regresión)