PostgreSQL 18.3 landed early because something broke

Three months after the first PostgreSQL 18 patch wave, the project shipped 18.3 out of schedule to clean up regressions and quiet a few scary edge cases.

And yes, this is one of those releases where the team says “minor,” but history suggests you should read the notes like you read a pager alert. Carefully, and with coffee.

The backstory: when a fix needs a fix

I have watched teams treat minor Postgres upgrades like a routine package bump, then spend the next morning chasing a replication stall they cannot reproduce in staging.

PostgreSQL 18.3 feels like it exists to stop that movie from playing again, because the release notes explicitly call out follow-up work tied to earlier CVE fixes (CVE-2026-2006 and CVE-2026-2007) and the regressions they triggered.

Small release. Loud signal.

One detail that matters if you track timelines for change windows: the official PostgreSQL release date for 18.3 is February 26, 2026, but the source tarballs on the PostgreSQL FTP site carry February 23 timestamps. That mismatch confuses people during incident reviews, so I mention it up front.

What actually changed (the stuff you feel in production)

The thing nobody mentions is that “bug fix” can mean “your standby stops applying WAL” or “your query returns the wrong rows,” which both count as bad days even if nobody calls it a security incident.

• Standby/WAL replay won’t fall over on older multixid truncation WAL records: PostgreSQL fixed a failure mode that could halt replay with “could not access status of transaction,” after a standby replays a multixid truncation record generated by an older minor version.
• substring() stops throwing bogus encoding errors on toasted data: the release notes say a prior fix for CVE-2026-2006 acted too aggressively and could reject valid input. 18.3 backs that off.
• pg_trgm strict_word_similarity() correctness (and a rare crash) got a patch: PostgreSQL fixed an oversight in the CVE-2026-2007 follow-up where pointer handling could break results, and in narrow conditions, crash.
• json_strip_nulls() and jsonb_strip_nulls() volatility marking got corrected: they should be IMMUTABLE, but a refactor accidentally marked them STABLE in v18. New clusters get the fix automatically. Existing clusters might need manual catalog surgery.
• LATERAL UNION ALL queries stop skipping NOT NULL checks in some plans: PostgreSQL fixed a planner/accounting bug that could produce wrong results by skipping NOT NULL tests.
• hstore’s binary input path won’t crash on duplicate keys: a null pointer dereference could take down a backend on corrupted or malicious input.

Other stuff in this release: constraint naming collision avoidance, wait-event stats for auxiliary processes, a PL/pgSQL cast bug. The usual.

So should you upgrade right now?

Depends.

If you run PostgreSQL 18 in production with streaming replication, or you lean on pg_trgm for search-like features, I would not wait for “the next normal minor.” Out-of-cycle releases do not happen because someone felt tidy. They happen because somebody hit a wall.

Some folks skip canaries for patch releases. I do not, but I get it, because the risk you fear depends on where you stand in the story.

• If you operate HA (Patroni, repmgr, managed replicas, anything): upgrade quickly, but roll through standbys first. You want one box taking the new binaries before your primary does.
• If this is a dev cluster you can recreate from Terraform in 20 minutes: just upgrade, verify, move on.
• If your distro repo lags upstream builds: you might need to wait for packages, or pull from your vendor’s repo. I have not tested every downstream packaging lag this week, so check your actual installed build.

The team does not list new CVEs in the 18.3 release notes. They do call out fixes related to earlier CVE patches. Treat this as “regression cleanup with sharp edges,” not a marketing “security bundle.”

The one gotcha: check json_strip_nulls() volatility on existing clusters

This bit me once in a different context: an “innocent” function volatility label can change planner behavior, and you only notice after a dashboard goes weird.

PostgreSQL 18.3 corrects json_strip_nulls() and jsonb_strip_nulls() back to IMMUTABLE for newly initialized clusters and pg_upgrade’d clusters. For an already-running 18.x cluster, the release notes include a manual fix:

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

Run it as a superuser, and do not forget your template databases if you rely on them. (Yes, people still do.)

How I’d upgrade it at 02:00 without ruining my weekend

Take the backup.

Then take five minutes to prove the backup restores somewhere, because a backup you did not test equals wishful thinking, and wishful thinking does not restore customer data.

• Preflight: record current version (SELECT version();), list extensions (\\dx), and note whether this node runs as primary or standby.
• Canary first: upgrade one standby or one low-traffic node, restart Postgres, then watch logs and replication lag for at least one business hour.
• Upgrade via your normal packaging path: apt, yum/dnf, vendor packages, or your container image pipeline. Keep the change small and reversible.
• Restart and verify: run SELECT version(); then hit a couple real queries, not just “psql connects.” Check your app error rate, connection pool churn, and replication state.

There’s probably a better way to test this, but…

Where to read the truth

If past releases are any guide, the only page that really matters is the official release notes, because they list the exact failure modes and the exact remediation SQL.

Read the official PostgreSQL 18.3 release notes, then compare them to what you run in prod. That last part sounds obvious, and it still trips people.