PostgreSQL 16.3 needs a catalog fix for existing databases

A server can report the patched PostgreSQL version while retaining the vulnerable definitions of its system views. That distinction is central to the May 9 maintenance release, which includes PostgreSQL 16.3. Its correction for CVE-2024-4317 applies automatically to freshly initialized clusters. Existing installations need an additional SQL operation to change the views in their databases.

The affected views are pg_stats_ext and pg_stats_ext_exprs. They expose extended statistics, and the missing authorization check could reveal data an authenticated user could not read directly. The security notice identifies PostgreSQL 14 through 16 as affected. The accompanying updates to PostgreSQL 12 and 13 contain maintenance work, but those branches are not part of this vulnerability's affected range.

I rely on PostgreSQL's predictable schema behavior, so this is an update where the catalog deserves explicit attention. Replacing the server executable and changing an existing database definition are different operations. A maintenance record needs to describe both when the security repair depends on both.

Statistics can contain protected values

The 16.3 release notes explain that the views failed to hide statistics for expressions involving columns the accessing user could not read. A column such as most_common_vals may disclose security-relevant data. The announcement also notes that these values can reveal results of functions that the reader cannot execute.

This makes the views a second route to information protected at the table or function boundary. The reader does not need direct access to the original row if a statistical summary contains the value of interest. Describing all statistics as harmless metadata would overlook that summaries can preserve actual values, especially when they report common values explicitly.

The repair restricts rows in these views to the owner of the associated table. The release notes explain that the possible interactions are not fully clear, and that the project chose this restriction to err on the side of safety. That is a deliberately conservative authorization decision. It avoids trying to infer whether every statistical expression can be exposed safely to another role.

This can also change what a statistics-inspection tool sees. A tool running under a non-owner role cannot assume that every previously visible row remains available after the repair. The same restriction that closes the information leak defines the new visibility rule. A missing row under that role is therefore relevant to how the repair works, rather than evidence that statistics necessarily disappeared from the database.

Existing catalogs need the supplied SQL script

The release provides fix-CVE-2024-4317.sql in the installation's share directory. Its location depends on the packaging, and the announcement gives /usr/share/postgresql/ as an example. There are separate scripts for the affected major versions. The instructions require selecting the script that matches the server's major version and executing it as a database superuser.

The command below is the documented psql form for that example location. It runs within a connection to the database being repaired.

\i /usr/share/postgresql/fix-CVE-2024-4317.sql

Each database in the cluster needs the operation. A successful invocation in one application database does not change the view definitions in the others. This is why a record that says only that the script ran is incomplete without identifying its database coverage. The repair's unit of application is smaller than the cluster whose binaries were updated.

The release notes say an error probably indicates the wrong script version and that running the correct script more than once will not hurt. That makes retry behavior different from guessing at a failed schema change. The project supplies the repair and describes its repeated execution. Rewriting the system views independently would introduce a different change from the one documented for this release.

Fresh clusters receive the corrected behavior through initdb. Existing clusters preserve their catalogs across a minor update, which is why the same binary version can accompany different view definitions until the script runs. The project explicitly states this limitation in both the announcement and migration notes. A version-only inventory cannot distinguish those two states.

Template databases affect databases created later

The instructions also require repairing template0 and template1. Omitting them leaves the vulnerability in databases created later. Template coverage is therefore part of the security change even if the current application databases have all been repaired. The source of a future database matters as well as the state of databases that already exist.

For template0, the announcement gives commands to allow connections temporarily and then disable them again. These commands surround the separate connection and execution of the repair script in that database.

ALTER DATABASE template0 WITH ALLOW_CONNECTIONS true;

After repairing the template, the documented restoration is explicit. It returns template0 to refusing ordinary connections.

ALTER DATABASE template0 WITH ALLOW_CONNECTIONS false;

This is a specific catalog-maintenance procedure, not a request to recreate the cluster. The update remains a minor release. PostgreSQL says users do not need a dump and reload or pg_upgrade to install it. The additional script addresses the view definitions that binary replacement alone leaves unchanged.

I consider the template requirement particularly useful information in the announcement. It identifies how a repaired running environment could still produce a vulnerable new database. That is a concrete connection between the maintenance operation and later provisioning behavior, without assuming that every database always comes from the same template.

The remaining fixes preserve useful distinctions

The release also corrects boolean partition pruning for IS NOT expressions. The notes explain that a null satisfies IS NOT FALSE, so discarding the null partition can produce an incorrect answer. That is a query-correctness repair with a different mechanism from the authorization change. Both belong to the maintenance release, but only one requires the described catalog script.

Another correction changes how EXPLAIN counts heap pages during bitmap heap scans. Pages without visible tuples were previously omitted. The new reporting counts all pages returned by the bitmap index scan, making the displayed work more complete. That matters to interpreting a plan without implying that every query's execution strategy has changed.

May's update includes cumulative maintenance fixes across all supported branches. For CVE-2024-4317 specifically, completion requires the supplied view repair in every affected existing database and its templates. Once those definitions are corrected, visibility follows the new table-owner rule, including for databases subsequently created from the repaired templates.