El Grupo Global de Desarrollo de PostgreSQL ha publicado una actualización para todas las versiones actualmente soportadas de PostgreSQL, incluyendo: 18.6, 17.11, 16.15, 15.19 y 14.24, además de la tercera versión beta de PostgreSQL 19. Esta actualización corrige 28 vulnerabilidades de seguridad y más de 110 errores reportados durante los últimos meses.

Esta versión se salta de la versión 18.4 a 18.6 de PostgreSQL 18. La versión 18.5 no llegó a publicarse debido a una regresión.

Hay tres problemas que pueden requerir pasos adicionales después de actualizar, descritos en detalle más adelante en el anuncio:

• Construcción paralela de índices GIN
• btree_gist
• ltree

Para una lista completa de los cambios, por favor consulte las notas de la versión.

Aviso de fin de vida de PostgreSQL 14

PostgreSQL 14 dejará de recibir correcciones el 12 de noviembre de 2026. Si estás ejecutando PostgreSQL 14 en un entorno de producción, te recomendamos que empieces a planificar la actualización a una versión más reciente y que todavía tenga soporte. Consulta nuestra política de versionado para obtener más información.

Problemas de seguridad

La siguiente lista contiene las vulnerabilidades de seguridad corregidas en esta actualización. Puedes encontrar más detalles sobre las vulnerabilidades y las versiones afectadas en los enlaces correspondientes:

• CVE-2026-6464: Un fallo temprano de psql COPY FROM STDIN procesa las líneas de datos como comandos de psql. (CVSS v3.1: 8.1)
• CVE-2026-6469: ALTER TABLE ALTER TYPE restablece el propietario de las estadísticas extendidas. (CVSS v3.1: 3.8)
• CVE-2026-6470: No se comprueba el privilegio USAGE sobre el tipo. (CVSS v3.1: 4.3)
• CVE-2026-6471: La decodificación lógica puede ejecutar dlopen sobre un archivo arbitrario. (CVSS v3.1: 7.2)
• CVE-2026-14662: tsvector y tsquery realizan asignaciones de memoria insuficientes debido a un desbordamiento de enteros. (CVSS v3.1: 8.8)
• CVE-2026-14663: pgcrypto, cuando se utilizan cifrados deshabilitados por OpenSSL, cifra y descifra silenciosamente como texto plano. (CVSS v3.1: 6.5)
• CVE-2026-14664: Un desbordamiento de búfer en el heap de expresiones regulares permite ejecutar código arbitrario. (CVSS v3.1: 8.8)
• CVE-2026-14666: La caché de seguridad a nivel de fila ignora las modificaciones de roles. (CVSS v3.1: 4.2)
• CVE-2026-14668: Una confusión de tipos de ctid en el estimador de selectividad permite divulgar información derivada de una lectura arbitraria. (CVSS v3.1: 8.1)
• CVE-2026-14669: Un desbordamiento de búfer en el heap de to_char permite ejecutar código arbitrario. (CVSS v3.1: 8.8)
• CVE-2026-14670: Un desbordamiento de búfer en el heap de objetos vinculados de plperl permite ejecutar código arbitrario. (CVSS v3.1: 8.8)
• CVE-2026-14671: Una confusión de tipos en la caché de planes de refint permite ejecutar código arbitrario. (CVSS v3.1: 8.8)
• CVE-2026-14672:  Una diferencia observable en las respuestas con valores no predeterminados de scram_iterations permite determinar la existencia de usuarios. (CVSS v3.1: 5.3)
• CVE-2026-14673:  amcheck no limpia el search_path que no es de confianza. (CVSS v3.1: 3.8)
• CVE-2026-14676: Un desbordamiento de búfer en el heap de pg_stat_statements permite ejecutar código arbitrario.  (CVSS v3.1: 8.8)
• CVE-2026-14677: En sistemas de 32 bits, pltcl y plperl realizan asignaciones de memoria insuficientes debido a un desbordamiento de enteros. (CVSS v3.1: 8.8)
• CVE-2026-14678: pg_trgm puede leer más allá del final del búfer durante picksplit. (CVSS v3.1: 4.3)
• CVE-2026-14679: Un desbordamiento de búfer en la pila durante la coincidencia de argumentos escribe 0x0 y 0x1 en la memoria del servidor. (CVSS v3.1: 8.2)
• CVE-2026-14680: Confusión de tipos mediante argumentos internal. (CVSS v3.1: 8.8)
• CVE-2026-14681: Aplicación incorrecta del cifrado GSSAPI cuando se utiliza conjuntamente con SSL. (CVSS v3.1: 4.2)
• CVE-2026-15741:La descomposición de expresiones (expression deparse) permite una inyección SQL mediante un argumento de EXTRACT. (CVSS v3.1: 8.8)
• CVE-2026-15742:  fuzzystrmatch puede escribir en direcciones prácticamente arbitrarias debido a un desbordamiento de enteros. (CVSS v3.1: 8.8)
• CVE-2026-16238: Una confusión de tipos en pg_restore_attribute_stats() permite ejecutar código arbitrario. (CVSS v3.1: 8.8)
• CVE-2026-16239:  Una confusión de tipos en CLOSE + DECLARE sobre cursores permite ejecutar código arbitrario.(CVSS v3.1: 8.8)
• CVE-2026-16241:  Un subdesbordamiento de enteros en ECPG puede provocar la caída del cliente. (CVSS v3.1: 3.8)
• CVE-2026-18024: La función ascii() lee más allá del final del búfer. (CVSS v3.1: 4.3)
• CVE-2026-18408: psql \unrestrict permite al superusuario del servidor de origen de pg_dump ejecutar código arbitrario en el cliente psql. (CVSS v3.1: 8.8)
• CVE-2026-19385: Un desbordamiento de búfer en el heap de pg_dump permite ejecutar código arbitrario. (CVSS v3.1: 8.8)

Correcciones de errores y mejoras

Esta actualización corrige más de 110 errores reportados durante los últimos meses.

El siguiente problema afecta únicamente a PostgreSQL 14, 15 y 16, pero se destaca en el anuncio debido a su gravedad:

• Se corrige un autobloqueo (self-deadlock) que podía producirse al reproducir WAL generado por una versión menor anterior. Esta regresión, introducida en el conjunto anterior de actualizaciones menores, podía provocar que un servidor standby que siguiera a un primario ejecutando una versión menor anterior quedara bloqueado.

El resto de los problemas enumerados a continuación afectan a PostgreSQL 18. Muchos de ellos también afectan a otras versiones soportadas de PostgreSQL.

• Se corrigen las construcciones paralelas de índices GIN para que actualicen correctamente el valor reltuples de la tabla en pg_class. Anteriormente, un proceso worker paralelo podía informar de un número de filas no inicializado, dejando reltuples con un valor incorrecto, incluyendo Infinity o NaN. Esto puede provocar que autovacuum y autoanalyze no procesen la tabla, y esta situación no se corrige automáticamente. Si tienes tablas con índices GIN, se recomienda comprobar que sus valores de reltuples sean razonables después de actualizar. Consulta la sección «Actualización» para saber cómo identificar y reparar las tablas afectadas.
• Se realizan varias correcciones en btree_gist, incluyendo el tratamiento de NaN para float4/float8, que podía producir resultados incorrectos en columnas que contienen NaN, y la ordenación correcta de valores bit/bit varying durante la construcción de índices. Después de actualizar, puede ser necesario reconstruir mediante REINDEX los índices btree_gist sobre columnas float o bit. Consulta la sección «Actualización».
• Se corrige un desbordamiento de enteros en las comparaciones de ltree. Los valores ltree que contienen más de aproximadamente 14.653 etiquetas podían compararse incorrectamente, lo que podía manifestarse como un índice B-tree corrupto. Si utilizas ltree, puede ser necesario reconstruir los índices afectados después de actualizar. Consulta la sección «Actualización».
• Se corrige el partition pruning para tablas particionadas por RANGE, de modo que la partición DEFAULT ya no se omita en los casos en que debería ser escaneada. Anteriormente, esto podía provocar que faltaran filas en los resultados de las consultas.
• Se realizan varias correcciones para tablas particionadas que tienen particiones basadas en foreign tables. Cuando el partition pruning en tiempo de ejecución determinaba que algunas particiones no necesitaban ser escaneadas, las solicitudes en curso hacia servidores externos no siempre se gestionaban correctamente, provocando errores.
• Se realizan varias correcciones en RETURNING con OLD y NEW.
• Se mejora el rendimiento de los hash joins cuando existen múltiples claves de unión y muchos valores NULL.
• Se realizan varias correcciones en el planner que podían producir resultados incorrectos en las consultas, incluyendo pruebas value IN (array) cuando el array podía estar vacío, y funciones de ventana COUNT() que utilizan una cláusula EXCLUDE o que carecen de ORDER BY.
• Se añaden comprobaciones que faltaban para determinar si las comparaciones de igualdad sobre tipos contenedores son susceptibles de utilizar hashing (arrays, tipos compuestos y rangos). Sin estas comprobaciones, el planner podía elegir un plan basado en hash que posteriormente fallaba durante la ejecución con el error "could not identify a hash function".
• Se corrige la asociación de particiones de índices que son exclusion constraints, lo que también corrige el dump/restore de restricciones de exclusión particionadas.
• Se corrige REINDEX CONCURRENTLY sobre un índice que respalda una restricción de unicidad diferible, lo que podía provocar informes falsos de violaciones de restricciones.
• Se restaura una optimización del index scan que convierte un patrón exacto de LIKE o una expresión regular en una condición de igualdad para el índice cuando las collations del índice y de la expresión son diferentes.
• Se realizan varias correcciones en jsonpath. Entre ellas, los operadores @? y @@ ahora generan correctamente un error cuando existe una variable no definida en la expresión de ruta. Anteriormente, como estos operadores no pueden proporcionar valores para las variables, una variable no definida se trataba como null JSON en lugar de generar un error. Esto también podía provocar un consumo ilimitado de memoria.
• Se garantiza que se bloquee el acceso a las tablas temporales de otras sesiones, lo que podía producir resultados incorrectos de manera silenciosa.
• Se corrigen los errores "no empty local buffer available" durante el acceso a tablas temporales cuando un valor elevado de effective_io_concurrency podía permitir que un único flujo de lectura consumiera todos los buffers locales.
• Se evita que autovacuum procese las bases de datos en el orden incorrecto: antes lo hacía comenzando por las de menor prioridad en lugar de las de mayor prioridad.
• Se restaura el modo failsafe de VACUUM por wraparound para que utilice todo el buffer pool compartido, como estaba previsto. Este problema había ralentizado los vacuum de emergencia.
• Se corrige una posible decodificación incorrecta de tuplas de índices durante los index-only scans de GiST y SP-GiST, que podía producir datos corruptos.
• Se corrige una condición de carrera en la detección de conflictos bajo el nivel de aislamiento SERIALIZABLE. Un conflicto podía no detectarse al examinar un índice B-tree inicialmente vacío, permitiendo que transacciones en conflicto hicieran COMMIT y rompiendo la serializabilidad.
• Se corrige el registro en WAL de operaciones que limpian bits en los visibility maps de las tablas. Esto podía provocar la generación de backups incrementales incorrectos o dejar potencialmente sin corregir escrituras de páginas parcialmente actualizadas (torn pages).
• Se corrige la decodificación lógica de transacciones preparadas vacías. Una transacción preparada sin cambios decodificables podía enviar COMMIT PREPARED o ROLLBACK PREPARED al output plugin sin un PREPARE previo, lo que rompe la replicación con el subscriber incorporado.
• Se realizan varias correcciones en libpq, incluyendo garantizar que se consuman todos los bytes pendientes del buffer de descifrado SSL o GSS al leer datos. Esto evita situaciones en las que un cliente espera datos que ya habían llegado.
• Se corrige pg_createsubscriber para que limpie los objetos que quedan en el publisher después de un fallo, incluyendo un replication slot.
• Se corrige pg_restore con --statistics o --statistics-only para que, cuando se combina con otras opciones de restauración selectiva como --schema, restaure los elementos esperados, de acuerdo con el comportamiento de pg_dump.

Actualización de datos de zonas horarias

Esta versión también actualiza los archivos de datos de zonas horarias a tzdata 2026c.

En esta versión:

• Alberta (America/Edmonton) pasará a utilizar UTC-06 durante todo el año —es decir, horario de verano permanente— a partir de noviembre de 2026.
• Esta versión asume que la abreviatura de zona horaria será CST a partir de ese momento, aunque esto podría cambiar.
• También se refleja que Marruecos (Africa/Casablanca) pasará a UTC+00 permanente, sin cambios por horario de verano, el 20 de septiembre de 2026.

Actualización

Todas las actualizaciones menores de PostgreSQL son acumulativas.

Al igual que ocurre con las demás versiones menores, no es necesario hacer un dump y recargar la base de datos ni utilizar pg_upgrade para aplicar esta actualización. Simplemente puedes detener PostgreSQL y actualizar sus binarios.

⚠️ Atención a los índices GIN

Si tienes tablas con índices GIN, se recomienda comprobar sus valores reltuples después de actualizar.

Un error anterior en la construcción paralela de índices GIN podía haber dejado reltuples con un valor incorrecto —incluyendo Infinity o NaN— que impide que autovacuum y autoanalyze procesen la tabla.

La siguiente consulta muestra las tablas que tienen un índice GIN junto con su reltuples actual:

SELECT DISTINCT t.oid::regclass, t.reltuples FROM pg_class t JOIN pg_index i ON t.oid = i.indrelid JOIN pg_class ic ON i.indexrelid = ic.oid WHERE t.relhasindex AND ic.relam = 2742;

Para cualquier tabla cuyo valor de reltuples parezca incorrecto, ejecuta ANALYZE sobre ella —o crea otro índice— para restablecer el valor.

btree_gist

Si utilizas btree_gist, deberías reconstruir mediante REINDEX los índices btree_gist sobre columnas float4 o float8 que puedan contener valores NaN, así como los índices btree_gist sobre columnas bit o bit varying.

Por ejemplo:

REINDEX INDEX your_index_name;

ltree

Si utilizas ltree y tienes índices B-tree sobre valores ltree con una cantidad muy elevada de etiquetas —más de aproximadamente 14.653— deberías reconstruir esos índices mediante REINDEX, ya que podrían estar corruptos.

Por ejemplo:

REINDEX INDEX your_index_name;

Los usuarios que hayan omitido una o más actualizaciones menores anteriores pueden necesitar realizar pasos adicionales después de la actualización. Consulta las notas de versión de las versiones anteriores para obtener los detalles.

Para más información, consulta las notas de versión.

Nota sobre la beta de PostgreSQL 19

Esta versión marca la tercera versión beta de PostgreSQL 19.

Siguiendo el espíritu de la comunidad open source de PostgreSQL, se recomienda encarecidamente probar las nuevas funcionalidades de PostgreSQL 19 en tus sistemas para ayudarnos a eliminar errores y otros problemas.

Aunque no recomendamos ejecutar PostgreSQL 19 Beta 3 en entornos de producción, sí recomendamos buscar formas de ejecutar las cargas de trabajo habituales de tus aplicaciones contra esta versión beta.

Tus pruebas y comentarios ayudan a la comunidad a garantizar que PostgreSQL 19 mantenga nuestros estándares de ofrecer una versión estable y fiable de la base de datos relacional open source más avanzada del mundo.

Puedes obtener más información sobre nuestro proceso de pruebas beta y sobre cómo contribuir:

https://www.postgresql.org/developer/beta/

Actualización a PostgreSQL 19 Beta 3

Para actualizar a PostgreSQL 19 Beta 3 desde una versión anterior de PostgreSQL, necesitarás utilizar una estrategia similar a la empleada para actualizar entre versiones major de PostgreSQL, por ejemplo:

• pg_upgrade
• pg_dump / pg_restore

Para obtener más información, consulta la sección de la documentación sobre actualizaciones.

Cambios desde Beta 2

Las correcciones y cambios incluidos en PostgreSQL 19 Beta 3 incluyen:

• Se revierte GROUP BY ALL.
• Varias correcciones para la nueva sintaxis de tablas temporales FOR PORTION OF.
• Varias correcciones para la nueva funcionalidad de sincronización de secuencias de replicación lógica, incluyendo una condición de carrera relacionada con REFRESH SEQUENCES.
• Se corrige un error "unexpected logical decoding status change" que podía producirse cuando la decodificación lógica se activaba de manera concurrente.
• Se corrigen problemas relacionados con cambios de propietario de las subscriptions.
• Se corrigen resultados incorrectos de consultas de postgres_fdw al hacer pushdown de una comparación de arrays como field = ANY($1) que implique una conversión implícita de tipos.
• Se corrige un crash durante las comprobaciones de foreign keys que implican una restricción UNIQUE que admite NULL.
• Se corrige el análisis de pg_plan_advice para los guiones bajos (_) en literales numéricos.
• Se corrige la ausencia de una cláusula FORMAT al hacer deparse de JSON_ARRAY(query).

Para una lista completa de las nuevas características y de los cambios, consulten las notas de la versión:

https://www.postgresql.org/docs/19/release-19.html

Pruebas de errores y compatibilidad

La estabilidad de cada versión de PostgreSQL depende en gran medida de que ustedes, la comunidad, prueben la próxima versión con sus cargas de trabajo y herramientas de prueba para detectar errores y regresiones antes del lanzamiento oficial de PostgreSQL 19. Dado que se trata de una versión beta, es posible que se produzcan cambios en los comportamientos de la base de datos, los detalles de las características y las API. Sus impresiones y pruebas ayudarán a determinar los ajustes finales de las nuevas funciones, así que les pedimos de favor que la prueben lo antes posible. La calidad de las pruebas de los usuarios contribuirá a definir el momento en el que podamos lanzar la versión final.

Una lista de los problemas abiertos está disponible al público en la wiki de PostgreSQL. Pueden reportar errores usando el siguiente formulario en el sitio web de PostgreSQL:

https://www.postgresql.org/account/submitbug/

Enlaces

• Descargas
• Información sobre las pruebas beta
• Notas de la versión Beta de PostgreSQL 19
• Problemas abiertos de PostgreSQL 19
• Reporte de errores
• Donaciones