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

PostgreSQL 18.7, 17.12, 16.16, 15.20 and 14.25 shipped on 12 November 2026 with 140+ bug fixes. Here is what to reindex, which backups to redo, and what the final PG 14 release means.

By Waseem Anjum · Published 2026-11-12 · Updated 2026-11-13 · https://fabwaseem.com/blog/postgres-18-7-minor-release

> **TL;DR:** PostgreSQL shipped 18.7, 17.12, 16.16, 15.20 and 14.25 on 2026-11-12 with over 140 bug fixes. Updating is a binary swap, but GIN, pg_trgm GiST and bpchar B-tree indexes may need a REINDEX, and incremental backup users should take a fresh full backup. 14.25 is the last PG 14 release.

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](https://www.postgresql.org/message-id/attachment/208544/20261112updaterelease.md) and the [release notes](https://www.postgresql.org/docs/release/). The announcement does not list CVE numbers for this release; check the [security page](https://www.postgresql.org/support/security/) 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.

| Major | Update release | Note |
|---|---|---|
| 18 | 18.7 | Current |
| 17 | 17.12 | |
| 16 | 16.16 | |
| 15 | 15.20 | |
| 14 | 14.25 | Final PG 14 release |
| 19 | RC 2 | GA planned 2026-11-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.

![Cards listing the post-update reindex and backup steps for GIN, pg_trgm GiST, bpchar B-tree, TOAST and incremental backups](https://res.cloudinary.com/wasicloudinary/image/upload/v1794473493/fabwaseem/projects/c3xkh1agtcxvl0lecjl2.jpg)

## 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:

```sql
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](https://fabwaseem.com/blog/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:

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

![Cards showing patch targets 18.7, 17.12, 16.16, 15.20 and 14.25 plus PostgreSQL 19 RC 2, GA date and tzdata 2026f](https://res.cloudinary.com/wasicloudinary/image/upload/v1794473500/fabwaseem/projects/xwqgpbytw5kkewczmugi.jpg)

## 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](https://fabwaseem.com/blog/postgresql-14-end-of-life-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](https://fabwaseem.com/blog/uuidv7-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.

## Questions

### Do I need pg_upgrade to install PostgreSQL 18.7?

No. According to the announcement, update releases are cumulative and you do not have to dump and reload or use pg_upgrade. You stop PostgreSQL and update the binaries. Some post-update steps such as reindexing may still apply.

### Which indexes should I reindex after updating?

The announcement names GIN indexes you suspect are affected, GiST indexes using gist_trgm_ops from pg_trgm, B-tree indexes on bpchar columns declared without a length, and tables showing missing chunk number errors after REINDEX CONCURRENTLY on a TOAST index.

### Is PostgreSQL 14 still supported?

No. PostgreSQL 14.25 is the final release of PostgreSQL 14. It no longer receives security or bug fixes, so production users should plan an upgrade to a supported major version.

### Should I redo my incremental backups?

The announcement recommends taking a new full backup after updating and using it as the base for later incremental backups, because several incremental backup bugs could produce corrupt backups.

### When is PostgreSQL 19 released?

PostgreSQL 19 RC 2 shipped with this update. The planned general availability date is 2026-11-19, unless an issue forces a delay or another release candidate.