freenode
Databases & Infrastructure

PostgreSQL 19 features face revert debate after LLM bug tally

Haas flags foreign-key batching, REPACK, and online checksums as post-freeze risk areas; Gustafsson offers a checksums revert while others urge caution.

Three large PostgreSQL 19 features are under active revert discussion after Robert Haas asked an LLM to rank post-feature-freeze fixes by severity and volume, then put the top results to the pgsql-hackers list.

The standouts were fast-path foreign-key checks and batching, REPACK and REPACK CONCURRENTLY, and online data checksums. Haas summarized roughly sixteen post-freeze fixes for the FK work (including an out-of-bounds write, nested SPI crashes, and several distinct classes of wrong enforcement), about twenty-eight for REPACK (including data-loss paths that also touched VACUUM FULL and CLUSTER, broken toast and generated-column handling, and ACL fixes), and about twenty-five for online checksums (mostly state-machine holes around checkpoints, promotion, base backups, and unlogged relations). A fourth item, UPDATE/DELETE FOR PORTION OF, drew security-related fixes but less revert heat.

Haas said he was "pretty scared" that the first three still carry a long tail of undiscovered bugs in critical areas. He also noted that REPACK CONCURRENTLY had already been cut back after a prerequisite was reverted, leaving it limited to one process cluster-wide, a scope he doubted would have been accepted if known from the start.

Daniel Gustafsson, a co-author of online checksums, said he would prepare a revert for that feature. Melanie Plageman pushed back, arguing there is no consensus yet and that easier LLM-assisted pressure testing may simply be surfacing bugs earlier than in past cycles rather than proving the designs uniquely unsound. Bruce Momjian questioned whether the cleanup volume is actually unusual by historical standards. Haas replied that he meant to open a conversation, not force a conclusion.

The exchange leaves PostgreSQL 19's late feature set unsettled: either the project ships with known high-churn subsystems in FK enforcement, table rewrite, and checksum enablement, or it strips major user-visible work close to release.