PostgreSQL 19 llega tarde, y la culpa es de la IA
Postgres 19 is late, and it's AI's fault
El lanzamiento de PostgreSQL 19 se retrasa hasta noviembre, fuera de la ventana habitual de septiembre-octubre. La causa: los LLM están encontrando una avalancha de bugs en un código de más de 30 años. Los commits de back-patch crecieron más del 60% en un año, y varias funcionalidades grandes se revirtieron tarde. El autor, desarrollador del proyecto, reflexiona sobre el desafío de mantener la calidad e innovar cuando la IA detecta fallos que los humanos nunca habrían visto.
Dado que tenemos cuarenta años de bugs que los humanos no pudieron encontrar pero que los LLM son bastante capaces de descubrir, ¿cómo vamos a ponernos al día alguna vez, y cómo seguirá innovando PostgreSQL?
- CharlesW
> Este año va a ser diferente. Lo más probable es que PostgreSQL 19 no se publique hasta noviembre… […] Entonces, ¿qué pasó? La respuesta corta es que los LLM pasaron. […] Hay una enorme cantidad de código, y ese código contiene una enorme cantidad de errores. […] Lo que es diferente ahora es que se ha vuelto muchísimo más fácil encontrar esos errores.
Esto parece… ¿bueno?
Que pueda perturbar un poco el ritmo de publicación "tradicional" del proyecto no parece terriblemente malo en vista de la alternativa, que es lanzar otra actualización importante con errores que aparentemente han estado persiguiendo al código base desde hace tiempo.
- tibbar
Hice un poco de búsqueda de errores asistida por IA en Postgres este verano entre trabajos, y la cosecha fue asombrosa. Múltiples anomalías de serialización (por ejemplo [0] [1] [2]), problemas de integridad de claves foráneas ([3] [4]), errores de corrección del planificador como [5]. Varias vulnerabilidades dignas de CVE. Un error de zona horaria imposible de arreglar [6]. La lista se hizo tan larga que tuve que priorizar qué tenía tiempo de reportar, y me conformé con una docena o dos de cientos de candidatos. Ahora imagina que el mundo entero hiciera esto.
[0] Write skew observado bajo aislamiento serializable:
https://www.postgresql.org/message-id/flat/CA+COZaBo+ZpKgMvx...
[1] Anomalía serializable: claves primarias duplicadas:
https://www.postgresql.org/message-id/flat/CA+COZaBOiiRPmEfX...
[2] SERIALIZABLE puede confirmar write skew después de la summarización SSI:
https://www.postgresql.org/message-id/flat/CA+COZaCtK=UQbeQw...
[3] Corregir la validación de claves foráneas temporales de filas preexistentes
https://www.postgresql.org/message-id/flat/CA+COZaChq_ukm2o7...
[4] Bloqueo perdido durante el toasting permite violación de FK
https://www.postgresql.org/message-id/flat/CA+COZaC-2-GQabq+...
[5] La poda de particiones puede excluir incorrectamente una partición predeterminada RANGE
https://www.postgresql.org/message-id/flat/CA+COZaDXrfTaBjLE...
[6] Comparaciones entre timestamp y timestamptz ordenadas de forma inconsistente bajo DST : https://www.postgresql.org/message-id/flat/c22286ad6268347c6...
- hopa
Siento que la IA es increíble para tareas de "búsqueda" de solo lectura (consultar esto, buscar errores, encontrar vulnerabilidades) pero no es tan buena para tareas de "escritura" como "añadir esta característica". Las tareas de búsqueda son fáciles de verificar, los cambios de código son mucho más difíciles de verificar
- droppedasbaby
Supongo que el verdadero desafío es descubrir cómo escalar la verificación, porque el descubrimiento ya no es el cuello de botella. Generar más informes de errores no se traduce necesariamente en correcciones más rápidas si el mismo pequeño grupo de mantenedores todavía tiene que validar los informes, revisar las correcciones, etc.
- ta93754829
"es culpa de la IA"
No me enteré de cuándo la IA se volvió responsable de las versiones de Postgres, ¿cuándo pasó eso?