Cilindros apilados sobre pedestal en tonos menta representando columnas de base de datos

PostgreSQL 19: Reflexiones sobre las características retiradas por Peter Eisentraut

octubre 20, 2026 Alfonso Moreno | Sysadmin Senior 5 Visitas 16 min de lectura

El 13 de octubre de 2026, LWN publicó un resumen del blog post que Peter Eisentraut, committer del core team de PostgreSQL, había escrito cuatro días antes. El texto llevaba un título deliberadamente incómodo: “The reverts will continue until morale improves”. Quien haya operado PostgreSQL en producción y haya esperado el equivalente digital de un parto en Linux, leerlo es sentir un hormigueo: alguien con autoridad está reconociendo en voz alta que algo no salió bien en el ciclo de PostgreSQL 19. Y, sobre todo, está explicando por qué.

Este artículo no traduce el texto de Eisentraut ni el coverage de LWN. Lo que vas a leer es mi lectura, en clave de sysadmin latinoamericano: por qué 8 a 10 features que parecían seguras se quedaron fuera, qué papel jugó el LLM-assisted review en detectarlas, y cómo te conviene a ti tomar la decisión de actualizar cuando PostgreSQL 19 salga como GA. Si operas PostgreSQL en un homelab, en un servidor de aplicaciones para tu negocio, o si tu equipo está en medio de una migración a la versión 18, esta nota te interesa.

Por qué este artículo importa a quien opera PostgreSQL en producción

Cuando un motor de base de datos con tres décadas de historia aplaza o revierte features que ya estaban mergeadas en su rama principal, eso te afecta por dos razones operativas. Primero, porque posiblemente contabas con alguna de esas features para una migración planeada o para un caso de uso que documentaste en una wiki interna. Segundo, porque detrás del ruido de “se reverte la feature X” hay decisiones de gobernanza que van a condicionar los próximos cinco años del motor: cuánto tarda un patch en estabilizarse, quién decide qué entra y qué se queda fuera, y cómo se mide la calidad de algo que combina SQL declarativo con catálogos de sistema, dominios, vistas, funciones security-definer y triggers en combinaciones que nadie puede enumerar a mano.

Para un sysadmin en México, Colombia, Chile o Argentina, PostgreSQL suele ser la primera parada seria cuando se sale de MySQL/MariaDB: viene en los repos oficiales de Debian, Ubuntu, Fedora y Rocky, y su comportamiento predecible en discos lentos o con poca RAM lo hace muy atractivo para hardware reciclado. Cada release anual es un evento discreto que toca decisiones reales: ¿actualizo la app ahora, espero tres meses al .1, salto a 19 directo desde 16?

El “scary patch contest”: el email que destapó todo

El 25 de agosto de 2026, Robert Haas, otro committer veterano de PostgreSQL, mandó un correo a la lista pgsql-hackers con el subject “scary patch contest”. Haas le pidió al LLM que estaba usando como asistente de revisión que evaluara cuáles patches de la rama v19 eran los más preocupantes según la cantidad y el tipo de bugs arreglados después del feature freeze. El correo, según reporta Joe Brockmeier en LWN, listaba varios candidatos preocupantes y cerraba con preguntas incómodas: ¿revertimos antes del GA, o aguantamos con un beta adicional?

El feature freeze de PostgreSQL 19 había sido el 8 de abril de 2026. Entre esa fecha y agosto, dice Eisentraut, los senior developers del proyecto estaban distraídos por la “Vulnpocalypse”: una serie de vulnerabilidades que exigieron atención inmediata y quitaron horas de revisión al tronco principal. Cuando en agosto se retomó el review intensivo, aparecieron tantas cosas que ya no daba tiempo a arreglarlas todas antes del GA planeado. La comunidad prefirió pegarse al calendario y revertir lo que no se podía estabilizar.

La consecuencia operativa: cerca de 8 a 10 features significativas no van a llegar en el PostgreSQL 19 GA. Algunas eran headline, otras eran internas, pero todas habían pasado el commitfest original y el feature freeze. Eisentraut estima, en su blog post, que probablemente unas pocas vuelvan al ciclo 20 maduras y otras se queden en el limbo por un año más.

Las features más afectadas: REPACK CONCURRENTLY, foreign keys y replicación lógica

LWN enumeró tres casos representativos. El primero fueron los patches de foreign-key fast-path de Amit Langote y Junwang Zhao: una vía rápida para validar foreign keys evitando el SPI y haciendo un index scan directo, más una capa de batching encima. Entre los dos, según Haas, hubo cerca de 16 fixes después del feature freeze, incluyendo cinco clases distintas de enforcement incorrecto (cross-type, dominios, orden de columnas, claves nullables, índices no-btree) y un rediseño del modelo transaccional del batching en plena beta.

El segundo caso fue REPACK CONCURRENTLY, contribución de Antonín Houska committeada por Álvaro Herrera. El comando REPACK existía hace tiempo para reescribir tablas compactadas sin lock prolongado; la versión CONCURRENTLY prometía hacerlo sin bloquear lecturas ni escrituras. Los dos patches acumulan 28 fixes desde el feature freeze, incluyendo casos de data loss y dos fixes de tipo ACL (access control list). Todavía hay un parche abierto que discute si se debe deshabilitar REPACK CONCURRENTLY sobre tablas del catálogo del usuario, un detalle que no es menor: si te automatiza una operación diaria sobre un catalog table, te puede tirar el cluster.

El tercer caso, no mostrado, fue la combinación de replicación lógica con secuencias, que ya había sido revertida en un ciclo previo y que vuelve a entrar con cambios. Esto es sintomático: features que ya pasaron por un revert una vez requieren una segunda oportunidad porque la complejidad del sistema no permite predecir todas las combinaciones.

Las seis causas que Eisentraut identifica

Eisentraut no carga las culpas sobre una sola causa. Dice que probablemente es una combinación de seis factores, y la proporción varía según la feature:

1. Código que simplemente no estaba lo suficientemente bueno. Eisentraut lo menciona primero para no dar la impresión de que todo se explica por lo que viene después.

2. Coincidencia. El equipo venía de varios ciclos exitosos y se animó a features ambiciosas que, en retrospectiva, eran demasiado difíciles para una ventana de tiempo realista.

3. LLM-assisted code review que encuentra defectos más rápido. Antes, bugs menores que solo aparecían en combinaciones raras de SQL se encontraban lentamente durante años. Ahora un LLM haciendo review puede listarte cuarenta reportes de defectos en una tarde. Cada uno requiere solo tres líneas de arreglo en promedio, pero el overhead fijo de gestionar cada reporte suma horas. Y se acaba el tiempo.

4. No fue “vibe coding”. Eisentraut aclara que el código revertido fue escrito antes de que el “vibe coding” fuera práctica común. La IA encontró bugs en código humano.

5. La Vulnpocalypse entre abril y agosto. Los senior developers que normalmente hubieran hecho el review adicional durante esos meses estaban apagando incendios de seguridad. El review se retomó tarde, los issues aparecieron tarde, los reverts sucedieron tarde.

6. La complejidad de “todo funciona con todo”. ¿Tu feature de query language funciona con dominios? ¿Con dominios sobre un tipo compuesto? ¿Donde un campo es también dominio? ¿Y si la tabla está particionada, se detachó y se reattachó? ¿Y si la vista está llamada desde una función security-definer que se dispara desde un trigger? Nadie puede enumerar esos casos a mano. Pero un LLM-assisted fuzzer los encuentra en minutos.

Cómo verificar hoy qué versión tienes y qué tienes habilitado

Antes de pensar en actualizar a PostgreSQL 19, conviene saber con qué estás trabajando realmente. El siguiente comando te devuelve la versión del servidor, el catálogo que está cargado y la configuración de búsqueda del binario, datos clave antes de tomar cualquier decisión de upgrade:

psql -U postgres -c "SELECT version();" -c "SHOW server_version_num;" -c "SHOW data_directory;" -c "SHOW config_file;"

La columna server_version_num devuelve un entero (por ejemplo 180005 para 18.5) que es lo que tu script de monitoreo debe comparar, no el string version(). Si tu número es 18.5 o superior, estás en la línea de release anterior a 19; si es 17.x todavía, tu ventana de upgrade es más cómoda porque 19 todavía está en beta. Si devuelve un número 16.x o menor, estás fuera del ciclo regular de parches: PostgreSQL 16 tiene EOL anunciado, conviene planear el salto.

Para listar las extensiones y los contribs disponibles en tu cluster actual, la consulta siguiente te da el panorama completo. Es útil porque varias de las features afectadas (por ejemplo, las que tocan replicación lógica) requieren módulos como pgoutput o pg_stat_statements cargados:

psql -U postgres -c "SELECT name, default_version, installed_version FROM pg_available_extensions WHERE installed_version IS NOT NULL ORDER BY name;"

Si installed_version aparece como NULL, la extensión existe en el catálogo pero no está habilitada todavía en tu base. Eso te dice qué tienes disponible sin tener que instalar paquetes adicionales antes de probar 19 en un sidecar.

El rol del LLM-assisted review: ni villano ni salvador

Vale la pena quedarse un momento en el punto 3 de Eisentraut, el que más debate generó en los comentarios de LWN. La lectura correcta no es “la IA rompió PostgreSQL”, sino: “la IA encontró bugs que un humano no iba a encontrar en este ciclo, y eso subió la barra de calidad efectiva después de que la feature ya estaba mergeada”. La penalización la pagan los commits viejos.

La “Vulnpocalypse” que vació al equipo de review

El término “Vulnpocalypse” lo acuñó la propia comunidad PostgreSQL para referirse a la seguidilla de vulnerabilidades severas que aparecieron entre abril y agosto de 2026. El detalle operativo importa: si tu equipo depende de PostgreSQL, esas vulnerabilidades también te tocaron. Cada CVE requirió coordinación entre disclosure, patch, build del paquete para tu distro, deploy, validación. Los senior maintainers del core son los mismos que revisan el trunk principal, así que la atención se fue toda para el lado de seguridad. La consecuencia no fue un PostgreSQL 19 roto, sino un PostgreSQL 19 con menos horas de review por feature que las que recibió la 18.

Si todavía no parcheaste la ronda de CVEs que PostgreSQL community release durante 2026, este es un buen momento para hacerlo antes de planear cualquier upgrade. Las versiones menores 16.x, 17.x y 18.x recibieron backports durante todo el año. Tu distro Linux probablemente ya los distribuyó como point release estándar: en Debian/Ubuntu corre apt list --upgradable | grep postgresql, en Fedora/RHEL dnf check-update postgresql*, en Arch pacman -Si postgresql. Si hay paquetes esperando, no postergues: la seguridad del motor de base es lo último que puedes dejar para el ciclo siguiente.

Qué queda en PostgreSQL 19: las que sí pasan el filtro

Eisentraut aclara que PostgreSQL 19 sigue siendo un release atractivo. Tres son las más visibles:

REPACK CONCURRENTLY. Después de los 28 fixes, pasa. El comando reescribe una tabla para compactarla sin lock prolongado, algo que llevaba años en el wishlist de quien opera bases grandes con alta concurrencia. La operación corre en background mientras la tabla sigue aceptando tráfico.

Logical replication of sequences. Esta feature ya había sido revertida en un ciclo previo. Vuelve en 19 después de trabajo adicional que demostró que se podía estabilizar. Para setups donde necesitas replicar secuencias sin re-sincronizar desde cero, es una mejora concreta.

pg_plan_advice (planner hinting). Es la versión PostgreSQL del “yo sé mejor que el planner qué índice usar aquí”, formalizado como advice persistente por sesión o por base. Reduce la cantidad de workarounds con pg_hint_plan en producción.

El siguiente bloque sirve para confirmar, una vez tengas PostgreSQL 19 instalado en un sidecar de prueba, que las tres features están efectivamente disponibles en tu binario:

psql -U postgres -c "SELECT name FROM pg_available_extensions WHERE name IN ('pg_repack', 'pgoutput', 'pg_plan_advice');"

Si tu binario devuelve al menos las tres filas, tu build incluye las features que la comunidad considera estables. Si falta alguna, probablemente estás contra un paquete de distro que recortó módulos; conviene probar el binario oficial de postgresql.org o el paquete de la comunidad PGDG antes de descartar la versión.

Para validar replicación lógica de secuencias sin tener un segundo cluster, puedes crear una publicación local y ver si las secuencias aparecen listadas como parte de los objetos replicables:

psql -U postgres -c "CREATE PUBLICATION test_pub FOR ALL TABLES WITH (sequences = true);" 
  -c "SELECT pubname, puballtables, pubsequencevalues FROM pg_publication WHERE pubname = 'test_pub';" 
  -c "DROP PUBLICATION test_pub;"

La columna pubsequencevalues debe devolver true si la feature está activa en tu build. Si devuelve false, el binario trae la sintaxis pero la opción no está habilitada todavía, probablemente porque estás contra un paquete de distro conservador.

Para verificar el comportamiento de pg_plan_advice en un escenario realista, el siguiente bloque carga el módulo en la sesión actual, persiste un advice y luego muestra cómo el planificador lo respeta:

psql -U postgres -c "CREATE EXTENSION IF NOT EXISTS pg_plan_advice;" 
  -c "SELECT pg_create_plan_advice('SELECT * FROM pg_proc WHERE proname = $1', 'pg_proc_proname_idx'::regclass);" 
  -c "EXPLAIN (FORMAT TEXT) SELECT * FROM pg_proc WHERE proname = 'now';"

Si el plan incluye Index Scan using pg_proc_proname_idx, el advice se está respetando. Si ves Seq Scan, la feature está disponible pero el advice no se aplicó: probablemente hay un conflicto con la cache de plans persistidos. Solución: limpia el cache con pg_stat_statements_reset() y repite la prueba.

¿Qué quedó afuera vs qué sí llega? Una tabla rápida

Feature	Estado en PG 19	Razón principal	Vuelve en PG 20
REPACK CONCURRENTLY	Sí entra	28 fixes post-freeze, estabilizado	Ya está
Logical replication of sequences	Sí entra (segundo intento)	Ya revertida antes, ahora estabilizada	Ya está
pg_plan_advice	Sí entra	Diseño defensivo, pasó review	Ya está
Foreign-key fast-path per-row	Sí entra	16 fixes, complejidad manejable	Ya está
Foreign-key batching	Revertida	Rediseño transaccional complejo	Probable
Mejoras internas a catálogos	Revertidas (varias)	Combinaciones con dominios/particiones	Incierto
Mejoras a planner	Mix (algunas sí, otras no)	Edge cases con vistas security-definer	Selectivo

La tabla es lectura operativa, no auditoría completa. Eisentraut habla de 8 a 10 features revertidas en total; los nombres exactos los puedes reconstruir siguiendo los hilos de pgsql-hackers desde septiembre de 2026 hasta el anuncio del beta final. Lo que importa para decidir tu upgrade es: PG 19 no es un release fallido, es un release conservador que dejó afuera features que la propia comunidad juzgó no estabilizables a tiempo.

¿Vale la pena actualizar cuando salga GA? Recomendación para sysadmins

Mi lectura, basada en lo que Eisentraut dice y en cómo se comporta el patrón histórico de PostgreSQL, es esta. PostgreSQL 19 GA va a llegar antes de fin de año. Los primeros tres meses (19.0, 19.1, 19.2) son los que más activamente reciben fixes; después el ritmo se estabiliza y la 18 empieza a perder peso. Si hoy estás en 17.x y tu carga es estable, te conviene esperar al 19.2 antes de tocar producción. Si estás en 16.x o menor, no esperes a 19: ve a 18.4 primero y planifica el salto a 19 desde ahí.

Si tienes alguna de las features revertidas en tu roadmap (foreign-key fast-path con batching, replicación lógica de secuencias antes de tiempo, o cualquier patch interno que tocaba catálogos), ajusta el timeline. Esas features no van a estar en 19; pueden volver en 20, pero no cuentes con ellas para 2026. Y si tu equipo está haciendo review de código que toca PostgreSQL con asistencia de LLM, esta historia es la confirmación de que necesitas un humano en el loop para los edge cases que el modelo no suele imaginar. PostgreSQL 19 va a ser un buen release, pero los próximos seis meses son para probarlo, no para deployarlo a ciegas.

TL;DR — Lo que te llevás de este artículo

Qué pasó: 8 a 10 features significativas fueron revertidas del branch PostgreSQL 19 durante el beta, después del feature freeze del 8 de abril de 2026.
Por qué pasó: seis factores combinados según Eisentraut, incluido LLM-assisted review que sube la barra de calidad, la “Vulnpocalypse” que consumió horas de los senior maintainers, y la complejidad combinatoria de “todo funciona con todo”.
Qué sí llega: REPACK CONCURRENTLY, logical replication of sequences, pg_plan_advice. PostgreSQL 19 sigue siendo un release atractivo.
Cuándo actualizar: espera al 19.2 si estás en 17.x; sal de 16.x ya, saltando a 18.4 antes de planear 19.
Qué revisar antes: tu versión real con server_version_num, las extensiones que tienes instaladas, y los point releases pendientes de seguridad.

Para terminar de leer el contexto antes de tocar nada, conviene saber qué queries están dominando tu carga. El módulo pg_stat_statements viene compilado en la mayoría de las distros pero no siempre está cargado. Activarlo te da visibilidad inmediata de qué se está ejecutando realmente, y es la única forma objetiva de saber si tus índices están rindiendo como pensás. El siguiente bloque verifica el módulo, lo carga si hace falta y devuelve las 10 queries más lentas:

psql -U postgres -c "SELECT * FROM pg_available_extensions WHERE name = 'pg_stat_statements';" 
  -c "CREATE EXTENSION IF NOT EXISTS pg_stat_statements;" 
  -c "SELECT substring(query, 1, 80) AS snippet, calls, round(mean_exec_time::numeric, 2) AS mean_ms FROM pg_stat_statements ORDER BY mean_exec_time DESC LIMIT 10;"

Si CREATE EXTENSION falla con “permission denied”, lo estás corriendo contra un usuario que no es superusuario; necesitas hacerlo como postgres o el rol equivalente. Si no devuelve filas, la extensión se cargó pero todavía no capturó tráfico: espera unos minutos con la base bajo carga normal y repite la consulta. Esta misma vista va a ser tu mejor amiga cuando notes regresiones después del upgrade a 19.

Preguntas frecuentes

¿Cuándo sale PostgreSQL 19 como GA?

Históricamente las releases mayores de PostgreSQL salen en septiembre u octubre. El ciclo 19 tuvo varios reverts que alargaron la beta. Se espera GA antes de fin de 2026, pero la fecha exacta la decide el release team; revisar postgresql.org/support/versioning/ para el anuncio oficial.

¿Las features revertidas vuelven en PostgreSQL 20?

Eisentraut dice que muchas de las que se quedaron fuera del 19 van a volver, posiblemente en el 20. La foreign-key batching y varias mejoras de replicación lógica son candidatas. Pero la velocidad de retorno depende del resultado del próximo ciclo de review.

¿Es seguro usar LLMs para escribir SQL contra PostgreSQL?

Sí, con un humano en el loop para los edge cases. El propio Eisentraut aclara que el código revertido fue escrito por humanos, no por IA. La IA encontró los bugs. El patrón se repite: usa LLM para acelerar la generación, pero reserva revisión humana para combinaciones complejas (dominios anidados, particiones detachadas/reattachadas, funciones security-definer).

¿Cómo me afecta la “Vulnpocalypse” si no uso PostgreSQL?

Si tu base es MySQL/MariaDB o un motor comercial, el patrón de reasignación de recursos hacia CVEs críticos te puede pasar también. Pero los CVEs que te tocan directamente son los de tu motor. Lo importante de este episodio es aprender cómo priorizar seguridad sin desatender el desarrollo principal.