PostgreSQL 19 se atasca: Haas abre el 'concurso de parches peligrosos
Varios parches destinados a la próxima versión mayor acumulan correcciones de errores en la recta final y el proyecto añade una beta extra para probarlos.
PostgreSQL 19 debía salir en septiembre, como manda la tradición de una versión mayor al año sin faltar a la cita. Pero a pocas semanas de la fecha, varias de las funcionalidades que iban dentro han levantado dudas sobre si el lanzamiento llega en condiciones. Uno de los parches ya se ha revertido, varios siguen en revisión intensa y el equipo ha metido una beta adicional en el calendario.
El 25 de agosto, el contribuidor Robert Haas envió un correo con un asunto que no deja lugar a interpretaciones: "scary patch contest". En él ponía el foco sobre varios parches que han acumulado una cantidad de correcciones de errores por encima de lo habitual en la recta final del ciclo. Si un cambio necesita arreglos una y otra vez antes de que se cierre el desarrollo, el riesgo de que llegue a producción con defectos crece, y eso en un proyecto que presume de estabilidad es una señal incómoda.
La respuesta ha sido doble. Por un lado, se ha revertido uno de los parches afectados, la salida más limpia cuando ya no hay margen para pulirlo. Por otro, los que quedan siguen sometidos a una revisión pesada, con revisiones y ajustes de calado sobre la mesa. El término que usó Haas no es habitual en las discusiones del proyecto, y esa elección de palabras tiene un efecto práctico: pone el asunto en el radar de todo el mundo antes de que el código se congele.
Una beta de más
El equipo ha decidido encajar una beta extra para dar más margen a las pruebas. No es una medida frecuente: cada beta adicional retrasa el calendario y obliga a los responsables de empaquetado, a los proveedores de servicios gestionados y a los mantenedores de extensiones a rehacer pruebas. A cambio, se gana tiempo para que los parches problemáticos se estabilicen o se caigan antes del lanzamiento.
El detalle del contenido de cada parche y de qué correcciones concretas se han aplicado no está desglosado en la información disponible, así que conviene mirar el estado del árbol antes de sacar conclusiones sobre qué funcionalidades llegarán finalmente a la versión estable.
Para quien administra bases de datos, el episodio es un recordatorio de por qué la .0 casi nunca es la versión que se pone en producción el primer día. PostgreSQL tiene un historial de calidad alto, y precisamente por eso llama la atención un aviso así. Queda por ver si la beta extra detecta lo que la revisión normal no detectó, cuántos de los parches señalados sobreviven al corte y si la fecha de septiembre aguanta. Los detalles del proceso de publicación y el estado de la documentación de la versión se siguen en la documentación de PostgreSQL 19.
