PostgreSQL 18.7 Update Release: Reindex Steps, Fixes, and PG 14 End of Life

PostgreSQL released 18.7, 17.12, 16.16, 15.20 and 14.25 on 12 November 2026. The announcement says it fixes over 140 bugs, and several of those fixes come with steps you need to run after you update. The commands below come from the official announcement.

Source: the PostgreSQL 20261112 update release announcement and the release notes. The announcement does not list CVE numbers for this release; check the security page for severity details.

Which versions shipped, and do I need pg_upgrade?#

All supported lines got an update, plus the second release candidate of PostgreSQL 19.

You do not need pg_upgrade or a dump and reload. The announcement says update releases are cumulative, and you can stop PostgreSQL and swap the binaries. If you skipped earlier update releases, read their notes too, because you may owe extra post-update steps.

Which indexes should I reindex?#

Four index-related fixes ask for a rebuild:

• GIN indexes. Several fixes address corruption that could make queries miss rows or return unrelated rows. If you suspect an index is affected, reindex it.
• pg_trgm GiST indexes. A fix for possible corruption that could miss matching rows. Reindex any GiST index using the gist_trgm_ops operator class.
• bpchar B-tree indexes. B-tree deduplication is now disabled for columns declared as bpchar without a length, because it could make index-only scans return wrong results. Reindex those indexes. Columns declared char(n) are not affected.
• TOAST after REINDEX CONCURRENTLY. After a concurrent rebuild of a TOAST table index, later index updates could be missed, leading to missing chunk number errors. If you saw that error, reindex the table, which also rebuilds its TOAST table.

The announcement gives these examples:

REINDEX INDEX your_index_name;
REINDEX TABLE your_table_name;

If you search text with trigrams, my earlier posts on Postgres full-text search vs Elasticsearch cover where GIN and GiST indexes fit.

What changed for backups?#

Two groups of backup fixes landed:

• Incremental backups. Several fixes address backups that could be corrupt. The recommendation is to take a new full backup after updating and base later incrementals on it.
• Base backups. Fixes avoid a torn copy of pg_control and truncated or zero-padded copies of files such as postgresql.auto.conf that are replaced while the backup runs.

There is also a standby fix: exporting and importing snapshots taken on a standby could corrupt a parallel pg_dump output and the standby's data. If you run pg_dump in parallel against a standby, this one matters.

What other data-correctness fixes are in it?#

The announcement lists many. The ones most likely to affect application teams:

• Possible row loss during a table rewrite (CLUSTER, VACUUM FULL) when a row had been updated by a subtransaction that later aborted.
• INSERT ... ON CONFLICT now takes a predicate lock on the conflicting row under SERIALIZABLE, so concurrent updates that should fail with a serialization error no longer succeed.
• MERGE with WHEN NOT MATCHED BY SOURCE when the target row is concurrently deleted could run a WHEN NOT MATCHED BY TARGET action.
• Several planner fixes that could return wrong results, including LATERAL, outer joins, self-join elimination on inheritance tables, and non-deterministic collations. The planner's join removal implementation was also reworked, which the announcement calls significant for an update release.
• Partition pruning fixes for multi-column RANGE partitions filtered on leading columns only, and DEFAULT partitions with MINVALUE or MAXVALUE bounds.
• NOT NULL NO INHERIT constraints on partitioned tables are now disallowed in every case, including CREATE TABLE ... LIKE.

To find existing NOT NULL NO INHERIT constraints on partitioned tables, the announcement provides this query:

SELECT conrelid::regclass, conname
FROM pg_constraint
WHERE contype = 'n' AND connoinherit
  AND conrelid IN (SELECT oid FROM pg_class WHERE relkind = 'p');

Drop what you do not want with ALTER TABLE ... DROP CONSTRAINT .... Repair the ones you keep with ALTER TABLE ... ALTER CONSTRAINT ... INHERIT, which fails if a partition has NULL values in that column.

What about PostgreSQL 14 and PostgreSQL 19?#

PG 14. The announcement states this is the final release of PostgreSQL 14, which no longer receives security and bug fixes. If you still run it in production, plan the major upgrade now. I wrote a walkthrough in PostgreSQL 14 end of life: how to upgrade.

PG 19. RC 2 shipped with this release. The planned GA date is 2026-11-19, unless an issue forces a delay or another candidate. Upgrading to a release candidate needs a major-version strategy such as pg_upgrade or pg_dump and pg_restore. If you use full text search, pg_trgm or fuzzystrmatch indexes with pg_upgrade, the announcement points you to the migration section of the PG 19 release notes, since you may need to reindex.

The update also refreshes time zone data to tzdata 2026f. It notes Canada's Northwest Territories (America/Inuvik) on year-round UTC-06, Manitoba (America/Winnipeg) on year-round UTC-05, and Cuba staying on daylight saving time this winter.

How should I roll this out?#

A practical order, based on the announcement:

1. Read the release notes for your major version, and for any update releases you skipped.
2. Update binaries on a staging copy first and run your own tests there.
3. Update production: stop, swap binaries, start.
4. Run the reindex steps that apply to you: GIN, gist_trgm_ops, bpchar B-tree, TOAST.
5. Take a fresh full backup if you use incremental backups.
6. If you use UUID keys, nothing here changes that choice, but see UUIDv7 in Postgres if you are reviewing index design anyway.

Large reindexes take time and I/O. Pick a quiet window, and consider whether REINDEX CONCURRENTLY suits your tables. The announcement does not say which to use, so check the reindex documentation for the locking trade-offs.

Key takeaways#

• 18.7, 17.12, 16.16, 15.20 and 14.25 shipped on 2026-11-12 with 140+ bug fixes.
• No pg_upgrade is needed for the minor update, but reindexing may be.
• Rebuild suspect GIN indexes, gist_trgm_ops GiST indexes and bpchar B-tree indexes.
• Take a new full backup if you rely on incremental backups.
• PG 14.25 is the final PG 14 release. Upgrade.
• PG 19 RC 2 is out, with GA planned for 2026-11-19.
• The announcement lists no CVE numbers; check the official security page for severity details.