Corrige un fallo después de reproducir un registro de truncamiento de multixid desde WAL que fue generado por una versión menor anterior (Heikki Linnakangas) §

Una lógica errónea para lidiar con la forma en que las versiones anteriores manejaban el desbordamiento (wraparound) de multixid conducía a un fallo de reproducción, con mensajes como “could not access status of transaction”. Un escenario típico en el que esto podría ocurrir es un servidor standby de la última versión menor consumiendo WAL de un servidor primario de una versión anterior.

Evita una queja incorrecta de codificación inválida cuando se aplica substring() a datos “toasted” (Noah Misch) § § §

La corrección para CVE-2026-2006 fue demasiado agresiva y podía generar un error sobre un carácter incompleto en casos que en realidad son válidos.

Corrige un descuido en la solución para CVE-2026-2007 (Zsolt Parragi) §

Si el arreglo “bounds” necesitaba expandirse, porque la entrada contenía más trigramas de lo estimado inicialmente, generate_trgm_only no devolvía el puntero del arreglo modificado a su invocador. Eso conducía a una salida incorrecta de strict_word_similarity() y funciones relacionadas, o en raros casos a una caída del servidor. El código defectuoso se alcanza si la cadena de entrada se vuelve más larga al convertirse a minúsculas. Los únicos casos conocidos de esto ocurren cuando se utiliza una colación ICU con ciertas codificaciones de un solo byte.

Corrige la marca de volatilidad de json_strip_nulls() y jsonb_strip_nulls() (Andrew Dunstan) §

Estas funciones siempre se han considerado inmutables (immutable), pero una refactorización en la versión 18 las marcó accidentalmente como estables (stable) en su lugar. Eso impide su uso en expresiones de índice y podría causar evaluaciones repetidas innecesarias en las consultas. Esta corrección corrige la marca en los clústeres de bases de datos recién inicializados (incluidos los clústeres que son actualizados con pg_upgrade a la versión 18.3 o posterior). Sin embargo, no ayudará a los clústeres existentes creados usando desde la versión 18.0 hasta la 18.2.

Si este error afecta tu uso de estas funciones, la corrección recomendada para un clúster existente es una actualización manual del catálogo. Como superusuario, ejecuta

UPDATE pg_catalog.pg_proc SET provolatile = 'i' WHERE oid IN ('3261','3262');

en cada base de datos afectada. Actualiza template0 y template1 también, para que las bases de datos creadas en el futuro tengan la corrección.

Corrige el cálculo del conjunto de joins externos que potencialmente pueden anularse (potentially-nulling outer joins) para la salida de una subconsulta LATERAL UNION ALL (Richard Guo) §

Este error podría conducir a omitir las pruebas NOT NULL bajo la creencia errónea de que eran innecesarias, resultando en una salida de consulta incorrecta.

Evita colisiones de nombres entre restricciones escritas por el usuario y restricciones NOT NULL nombradas automáticamente (Laurenz Albe) §

A partir de la versión 18, las restricciones NOT NULL tienen entradas de pleno derecho en pg_constraint, y por lo tanto requieren nombres. El algoritmo para elegir un nombre para una restricción NOT NULL sin nombre no logró evitar conflictos con restricciones escritas por el usuario en otras partes de la misma sentencia CREATE TABLE.

Corrige pg_stat_get_backend_wait_event() y pg_stat_get_backend_wait_event_type() para reportar valores de procesos auxiliares (Heikki Linnakangas) §

Anteriormente, estas funciones devolvían NULL para los procesos auxiliares, pero eso es inconsistente con la vista pg_stat_activity.

Corrige la conversión de una variable de tipo compuesto a un tipo de dominio cuando se devuelve su valor desde una función PL/pgSQL (Tom Lane) §

Si el valor de la variable es NULL, resultaba en un error “cache lookup failed for type 0”.

Corrige una posible desreferencia de puntero nulo en la función de entrada binaria de contrib/hstore (Michael Paquier) §

La función de recepción de hstore fallaba con entradas que contenían claves duplicadas. Los valores de hstore generados por Postgres nunca contendrían claves duplicadas, por lo que este error había pasado desapercibido. La caída podía ser provocada por datos maliciosos o corruptos.