Supported Versions: 16

E.1. Release 16.13 #

Release date: 2026-02-26

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

E.1.1. Migration to Version 16.13 #

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

However, if you are upgrading from a version earlier than 16.10, 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 computation of the set of potentially-nulling outer joins for the output of a LATERAL UNION ALL subquery (Richard Guo) §

    This error could lead to skipping NOT NULL tests in the mistaken belief that they were unnecessary, resulting in wrong query output.

  • 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.

Submit correction

If you see anything in the documentation that is not correct, does not match your experience with the particular feature or requires further clarification, please use this form to report a documentation issue.