PostgreSQL 18.6, el Beta 3 de PG19 y la Cuenta Atrás del EOL de PostgreSQL 14

Tres noticias de PostgreSQL convergen en este trimestre de 2026 y afectan a casi cualquier equipo con Postgres en producción: la release 18.6 con correcciones de seguridad y un bug sutil de índices, el Beta 3 de PostgreSQL 19, y el fin de soporte de PostgreSQL 14 el 12 de noviembre. Vamos por partes.

PostgreSQL 18.6: seguridad y un bug que no se autocorrige

La release del 13 de agosto de 2026 (18.6, 17.11, 16.15, 15.19 y 14.24) corrige 28 vulnerabilidades y más de 110 bugs. Ojo al salto de versión: 18.5 nunca se publicó por una regresión detectada después del wrap, así que de 18.4 se salta directamente a 18.6.

El bug de reltuples en índices GIN

El más insidioso de los fixes: los builds paralelos de índices GIN podían dejar el valor reltuples de la tabla en pg_class con valores absurdos (Infinity o NaN). La consecuencia es grave y silenciosa: autovacuum y autoanalyze dejan de procesar la tabla, y no se recupera solo.

Si tienes tablas con índices GIN, comprueba después de actualizar:

sqlCopiar
SELECT relname, reltuples
FROM pg_class
WHERE reltuples IN ('Infinity'::float8, 'NaN'::float8)
   OR reltuples < 0;

Valores corruptos se reparan con un ANALYZE manual sobre la tabla afectada o un REINDEX del índice GIN.

Seguridad: plugins de logical decoding y pgcrypto

Dos cambios de seguridad requieren acción:

• output_plugin_libraries: nuevo parámetro que restringe qué output plugins puede seleccionar un usuario de replicación (CVE-2026-6471). Por defecto solo permite pgoutput y test_decoding. Si usas otros plugins de logical decoding, debes añadirlos explícitamente antes de hacer pg_upgrade — el --check fallará si no.
• pgcrypto: corregido un fallo donde cifrados no soportados por OpenSSL (blowfish, twofish, cast5, 3des) producían "cifrado" trivialmente rompible (CVE-2026-14663). Ahora pgp_pub_decrypt/pgp_sym_decrypt fallan sobre datos afectados; existe la opción ignore-cipher-failure=1 para recuperarlos y re-cifrarlos con un algoritmo moderno.

También conviene revisar índices btree_gist sobre columnas float/bit e índices ltree — ambos tienen fixes que pueden requerir REINDEX.

PostgreSQL 14: EOL el 12 de noviembre de 2026

La noticia con fecha límite: PostgreSQL 14 deja de recibir fixes el 12 de noviembre de 2026. Si tienes producción en PG14, estás a tres semanas de correr una base de datos sin parches de seguridad.

Opciones de migración:

• PG 17 o 18 para máxima vida útil del salto. PG18 añade I/O asíncrono (hasta 3x en lecturas desde storage), columnas generadas virtuales y uuidv7().
• pg_upgrade con --link para minimizar downtime en upgrades mayores.
• Logical replication si el downtime permitido es casi cero: réplicas en la versión nueva, cutover controlado.

Hace un año escribimos sobre optimización de PostgreSQL en producción; gran parte de esas técnicas se benefician directamente del subsistema de I/O asíncrono de PG18, otro argumento para el salto.

PostgreSQL 19 Beta 3

El mismo anuncio incluyó el tercer beta de PostgreSQL 19. Es para testing, no para producción — pero si mantienes extensiones o herramientas sobre Postgres, este es el momento de probar compatibilidad. La versión final se espera siguiendo el ciclo habitual de releases anuales del proyecto.

Checklist

1. Actualiza a las últimas minors (18.6 / 17.11 / 16.15 / 15.19 / 14.24) — 28 CVEs son demasiados para posponer.
2. Audita reltuples en tablas con índices GIN tras actualizar.
3. Configura output_plugin_libraries si usas logical decoding con plugins externos.
4. Planifica el upgrade desde PG14 antes del 12 de noviembre. Si estás leyendo esto en esa versión, el reloj ya corre.

La buena noticia: todas estas acciones son operaciones conocidas. La mala: la fecha límite de PG14 no va a moverse.