PostgreSQL 19 retrasa las consultas gráficas SQL/PGQ por bugs críticos
El equipo de desarrollo ha eliminado el soporte para graph queries de la versión 19, aunque introduce REPACK CONCURRENTLY para reducir los bloqueos en producción.
PostgreSQL ha sacado el soporte para consultas de grafos SQL/PGQ de la versión 19. El motivo no es falta de tiempo, sino que hay bugs sin resolver que, según el equipo, podrían ser inmutables hasta la versión 20. Tom Lane, contributor de larga data, lo puso negro sobre blanco: apostaría una cena a que si se lanza en v19, llegarán fallos post-release que no se podrán parchear en esa misma versión.
La especificación SQL/PGQ se estandarizó en 2023 y ofrece sintaxis para explorar relaciones entre nodos conectados por aristas. Sin embargo, la implementación en PostgreSQL no cumplía con los estándares de calidad que la comunidad exige antes de un lanzamiento estable. Tom Kincaid, de EDB, confirmó que la función no estará en la 19. La quarta beta sigue programada para el 24 de septiembre, pero la fecha final de la GA sigue sin confirmarse.
Menos llamadas a medianoche con REPACK
Aunque las grafos se quedan fuera, los administradores de base de datos sí recibirán una mejora operativa significativa: la nueva sentencia REPACK con la opción CONCURRENTLY. Actualmente, para recuperar espacio en disco consumido por versiones obsoletas de filas, los DBAs usan VACUUM FULL. Este comando reescribe la tabla completa y mantiene un bloqueo exclusivo sobre la tabla durante todo el proceso, bloqueando lecturas y escrituras. Como bien sabe cualquier sysop, esto suele traducirse en caídas de servicio o, en el mejor de los casos, en llamadas urgentes de clientes que no pueden acceder a sus datos.
REPACK CONCURRENTLY permite que otras transacciones accedan a la tabla durante la mayor parte de la operación. El bloqueo exclusivo solo se aplica al final, cuando se intercambian los archivos de tabla e índices reescritos, un momento que suele ser muy breve. Si no se usa la opción concurrente, el bloqueo se mantiene todo el tiempo, igual que en VACUUM FULL. Para quien gestiona bases de datos en producción, esta distinción es la diferencia entre una tarea rutinaria y una interrupción planificada.
La comunidad prefirió priorizar la estabilidad del kernel y las utilidades de mantenimiento antes que añadir una funcionalidad de consulta que aún no estaba fiable. Para el usuario final, esto significa esperar un poco más para consultar grafos nativos, pero ganar una herramienta para mantener la salud de la base de datos sin sacrificar la disponibilidad.
Los que trabajen con grafos en PostgreSQL por ahora deberán seguir usando soluciones alternativas o esperar a la versión 20. Los que sufran con la degradación del rendimiento por bloat de tablas ya pueden empezar a probar REPACK en entornos de staging para ver si el comportamiento concurrente se ajusta a sus ventanas de mantenimiento.
