Documentation PostgreSQL 14.22 » Annexes » Notes de version » Release 14.22

Précédent | Niveau supérieur | Suivant
Annexe E. Notes de version | Sommaire | E.2. Release 14.21

## E.1. Release 14.22

Release date: 2026-02-26

This release contains a small number of fixes from 14.21. For information about new features in major release 14, see Section E.23.

The PostgreSQL community will stop releasing updates for the 14.X release series in November 2026. Users are encouraged to update to a newer release branch soon.

### E.1.1. Migration to Version 14.22

A dump/restore is not required for those running 14.X.

However, if you are upgrading from a version earlier than 14.19, see Section E.4.

### E.1.2. Changes

- Fix failure after replaying a multixid truncation record from WAL that was generated by an older minor version (Heikki Linnakangas) §

  Erroneous logic for coping with the way that previous versions handled multixid wraparound led to replay failure, with messages like « could not access status of transaction ». A typical scenario in which this could occur is a standby server of the latest minor version consuming WAL from a primary server of an older version.

- Avoid incorrect complaint of invalid encoding when `substring()` is applied to « toasted » data (Noah Misch) § § §

  The fix for CVE-2026-2006 was too aggressive and could raise an error about an incomplete character in cases that are actually valid.

- Fix `pg_stat_get_backend_wait_event()` and `pg_stat_get_backend_wait_event_type()` to report values for auxiliary processes (Heikki Linnakangas) §

  Previously these functions returned NULL for auxiliary processes, but that's inconsistent with the `pg_stat_activity` view.

- Fix casting a composite-type variable to a domain type when returning its value from a PL/pgSQL function (Tom Lane) §

  If the variable's value is NULL, a « cache lookup failed for type 0 » error resulted.

- Fix potential null pointer dereference in `contrib/hstore`'s binary input function (Michael Paquier) §

  `hstore`'s receive function crashed on input containing duplicate keys. `hstore` values generated by Postgres would never contain duplicate keys, so this mistake has gone unnoticed. The crash could be provoked by malicious or corrupted data.