E.2. Release 18.3
Prev | Up | Appendix E. Release Notes | Home | Next

## E.2. Release 18.3 #

Release date: 2026-02-26

This release contains a small number of fixes from 18.2. For information about new features in major release 18, see Section E.5.

### E.2.1. Migration to Version 18.3 #

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

However, if you are upgrading from a version earlier than 18.2, see Section E.3.

### E.2.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 oversight in the fix for CVE-2026-2007 (Zsolt Parragi) §

  If the “bounds” array needed to be expanded, because the input contained more trigrams than the initial guess, `generate_trgm_only` didn't return the modified array pointer to its caller. That would lead to incorrect output from `strict_word_similarity()` and related functions, or in rare cases a crash. The faulty code is reached if the input string becomes longer when it's converted to lower case. The only known instances of that occur when an ICU locale is used with certain single-byte encodings.

- Fix the volatility marking of `json_strip_nulls()` and `jsonb_strip_nulls()` (Andrew Dunstan) §

  These functions have always been considered immutable, but refactoring in version 18 accidentally marked them stable instead. That prevents their use in index expressions and could cause unnecessary repeat evaluations in queries. This fix corrects the marking in newly-initialized database clusters (including clusters that are pg_upgrade'd to 18.3 or later). However it will not help existing clusters made using 18.0 through 18.2.

  If this mistake affects your usage of these functions, the recommended fix for an existing cluster is a manual catalog update. As superuser, perform

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

  in each affected database. Update `template0` and `template1` as well, so that databases made in future will have the fix.

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

- Avoid name collisions between user-written constraints and automatically-named `NOT NULL` constraints (Laurenz Albe) §

  As of version 18, `NOT NULL` constraints have full-fledged `pg_constraint` entries, and therefore require names. The logic for choosing a name for an unnamed `NOT NULL` constraint failed to avoid conflicts with user-written constraints elsewhere in the same `CREATE TABLE` statement.

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

Prev | Up | Next
E.1. Release 18.4 | Home | E.3. Release 18.2