PostgreSQL 17.5 repairs GB18030 validation and persistent metadata

The May PostgreSQL update contains a security fix whose trigger is an incomplete character at a memory boundary. It also contains correctness fixes whose effects can remain in stored database objects after an upgrade. These require different completion criteria. Replacing vulnerable code prevents the encoding over-read, while previously created constraints and index summaries may need explicit reconstruction.

The May 8 announcement releases PostgreSQL 17.5, 16.9, 15.13, 14.18 and 13.21. It identifies CVE-2025-4207 and more than sixty maintenance fixes. The distinction between code replacement and stored-state repair is the most useful way to read this particular update.

PostgreSQL remains my relational default after decades of production use. That preference depends partly on being able to understand what an update actually requires. The May notes are explicit that an ordinary minor-version installation procedure can coexist with additional work on affected objects.

A length check must precede the read

The security advisory describes a one-byte buffer over-read during validation of malformed GB18030 text. A database input provider can cause temporary denial of service on platforms where that read can terminate the process. The affected code exists in both the database server and libpq, so the relevant software inventory includes client applications.

The advisory describes an availability problem. It does not claim that the defect lets an attacker alter database records or read arbitrary database contents. Keeping that scope explicit matters when explaining what the patch changes and why a client-library copy can be relevant even when the database server is already updated.

The 17.5 validator implementation makes the boundary condition concrete. Its GB18030 character verifier tests the remaining length before inspecting bytes needed for multibyte forms. The four-byte path starts with len >= 4, and the two-byte path starts with len >= 2.

That ordering is essential for incomplete input. A validator must decide that bytes are available before reading them to decide whether the character is valid. Rejecting malformed text eventually is insufficient if the rejection procedure itself has already read beyond its allocation. This is an inference from the corrected code and the advisory's stated trigger.

The database encoding is only part of the path

PostgreSQL's character-set reference distinguishes client encodings from the database's server encoding. GB18030 is supported as a client encoding, and the system supports conversion between client and server character sets. A deployment using another database encoding cannot infer from that fact alone that no component handles GB18030 input.

The same reference documents session-level inspection of the client setting. The query is useful for identifying the encoding of a particular connection:

SHOW client_encoding;

That observation has a defined scope. It says what the current session uses, without establishing what a separate libpq application or another connection accepts. Since the advisory includes libpq, updating the server package and identifying the library used by clients are distinct tasks. The vulnerable operation is validation of claimed input encoding, rather than storage of a particular table's text values.

Some foreign keys need their catalog entries rebuilt

The 17.5 migration notes identify self-referential foreign keys on partitioned tables. Creating or attaching partitions after defining such a constraint could omit necessary catalog entries and leave enforcement incomplete. The prescribed repair is to drop and recreate affected constraints after updating.

The notes also explain why recreation can fail. Rows that violate the intended constraint may already exist, and those rows need correction before the constraint can be recreated. A successful server restart therefore cannot establish that this repair is finished.

The constraint documentation defines a foreign key as a requirement that referencing values match a row in the referenced table. A self-reference applies that requirement within the same table. This is a data relationship, so the repair has to reconcile both the declared relationship and any rows admitted while enforcement was incomplete.

The operational implication follows directly. Installing corrected partition-management code prevents future creation of the defective metadata, but does not invent missing catalog entries for existing objects. Recreating the constraint asks the corrected implementation to establish the relationship again against the data now present.

A lossy index still has to include every possible match

The update also corrects merging of compressed BRIN bloom summaries. The release notes say missed data in a merged summary could cause index searches to omit matching rows. They advise considering reindexing existing BRIN bloom indexes after updating. This issue is separate from the encoding vulnerability.

The BRIN documentation explains the underlying contract. BRIN stores summaries for adjacent page ranges and can skip ranges inconsistent with the search condition. The executor rechecks candidate tuples, because a summary may include rows that do not actually match. Bloom operator classes use a Bloom filter to summarize values within the range.

That design tolerates extra candidate rows, since rechecking can discard them. An incomplete summary creates a different problem. If it excludes a range that contains a match, the executor never receives that row to recheck. Calling an index lossy does not permit it to omit true matches. Rechecking is a filter over selected candidates, so it cannot recover a candidate that the summary caused the scan to skip entirely.

I find this distinction useful when reading index-corruption reports. The important question is which decisions depend on the stored summary. A corrected merge function governs subsequent work, while an existing incorrect summary can continue influencing query results until the index is rebuilt.

The REINDEX reference describes rebuilding an index from its table data. That provides the relevant repair mechanism here. May's update can be installed without a dump and reload, but affected installations still need to account for the specific constraints and BRIN bloom indexes described in its migration notes.