PostgreSQL 16.1 requires index repair beyond installing new binaries

Replacing PostgreSQL binaries does not rebuild an index created under a faulty implementation. That distinction matters in the November maintenance releases, which repair index behavior alongside three security vulnerabilities. An installation can run the corrected executable while retaining an index whose earlier construction can still produce wrong answers. The update instructions therefore include reindexing affected structures.

The November 9 announcement covers PostgreSQL 16.1, 15.5, 14.10, 13.13, 12.17 and 11.22. The release also contains more than 55 bug fixes reported over the preceding months. It identifies CVE-2023-5868, CVE-2023-5869 and CVE-2023-5870 as the security issues. CVE-2021-32027 appears as an earlier array fix whose coverage was incomplete. It is not the third new vulnerability in this release.

I value PostgreSQL's documented maintenance procedures because they expose this difference between corrected code and existing state. A version inventory is useful, but it does not establish that a previously built index now satisfies the assumptions of the repaired implementation.

GiST page splits can leave wrong search behavior

The 16.1 release notes describe an error during recursive page splitting in a GiST index build. PostgreSQL could incorrectly track a page downlink's location. The consequences include wrong answers from later index searches. The fix also adds logic to recover from these situations instead of silently continuing incorrectly.

This is a persistent-state concern because subsequent searches consume the structure produced during the earlier build. Correcting future split handling does not reconstruct every previously affected index. The release notes say reindexing all GiST indexes may be advisable, and the release announcement recommends doing so after installing the update.

That recommendation concerns a class of index structures, rather than a claim that every row in every GiST-indexed table has been damaged. Reindexing reconstructs the index from the table's data under the corrected implementation. It addresses the structure used to locate candidate rows, which is where the release locates the defect.

Interval equality breaks B-tree deduplication assumptions

A separate correction prevents B-tree deduplication for interval columns. PostgreSQL can distinguish interval values that compare equal, and the release notes give 24 hours and one day as an example. B-tree deduplication made an assumption that does not hold for those values. That could produce incorrect results from index-only scans.

The correction excludes interval columns from deduplication. Existing B-tree indexes containing interval columns need rebuilding, and the release notes say amcheck will report errors for almost all such indexes after the update. Treating that diagnostic as proof of a newly introduced binary defect would miss the reason the release calls for reindexing stored structures.

The announcement gives a concurrent reindexing form for PostgreSQL 12 and later. Using the real affected index name in place of the example identifier rebuilds that index while avoiding the write blocking described in the announcement.

REINDEX INDEX CONCURRENTLY your_index_name;

That version qualification matters because the maintenance set also includes PostgreSQL 11. The command shown in the update announcement is not a promise that every included major version supports the same concurrent operation. The correct procedure follows the capabilities of the branch actually running.

BRIN corrections have a different consequence

The release also recommends rebuilding some BRIN indexes using minmax_multi operator classes with date or timestamp values. For dates, the distance calculation was backward, leading to poor choices about which entries to merge. For timestamp values, infinities and extreme finite values could also produce poor merging decisions.

The release notes explicitly say these indexes still return correct results. Their problem is efficiency. That distinguishes this recommendation from the GiST and interval B-tree issues, whose stated consequences include incorrect answers. All appear in the update instructions, but their reasons are different.

For timestamp and timestamptz BRIN indexes, the detailed notes tie the recommendation to columns containing, or previously having contained, infinities or very large finite values. That history matters because the stored summaries can retain the consequences of earlier data. The current visible values alone need not describe how the index acquired its present organization.

The security fixes cover three mechanisms

CVE-2023-5868 concerns certain aggregate calls with unknown-type arguments. The release notes identify DISTINCT aggregates with an any argument type and explain that a text value could be interpreted as a zero-terminated unknown value. That can disclose server memory beyond the text. The announcement does not establish reliable extraction of particular confidential information.

CVE-2023-5869 adds missing overflow checks when computing new array dimensions. Assigning elements outside existing bounds could otherwise lead to memory corruption, potentially permitting arbitrary code execution, or to reading server memory. The advisory scope is authenticated database users. Its relationship to the older CVE is incomplete prior coverage, rather than evidence that the old identifier has become a new disclosure.

CVE-2023-5870 repairs the authority of pg_signal_backend. Some background processes advertise a role OID of zero, and the permission check failed to treat that as superuser ownership. A role documented as unable to signal superuser backends could signal those processes. Core workers generally restart, so the announcement identifies a less resilient extension worker as the meaningful denial-of-service case.

My preference is to keep these scopes separate in an upgrade explanation. Array memory corruption, aggregate memory disclosure and background-worker signaling have different prerequisites. Reindexing addresses another kind of consequence altogether, one that binary replacement alone cannot resolve.

PostgreSQL 11 reaches its announced endpoint

The announcement identifies 11.22 as PostgreSQL 11's final release and says that branch will receive no further security or bug fixes. That changes the maintenance position for installations remaining on 11 even after they apply this update. They have the final corrections for that branch, while future defects require moving to a supported major version.

For existing installations within a major version, the update remains cumulative and does not require a dump and reload. The extra work comes from the explicitly identified index rebuilds and any earlier skipped maintenance requirements. Completing the November update therefore includes both installing the appropriate branch release and accounting for the persistent index structures named in its instructions.