Story
The reverts will continue until morale improves
1 report
1 website
1 discussion
Latest report
Overview
PostgreSQL 19’s development branch has reverted roughly eight to 10 significant features after its beta period began, far above the roughly one revert per release cycle that may be expected. Some reversions occurred late in beta. PostgreSQL developer Peter Eisentraut said the affected code may in some cases have been insufficient, while other features proved too difficult to complete on schedule or had architectural defects that could not be fixed quickly. Eisentraut said LLM-assisted code review and fuzzing can uncover edge cases much faster than earlier testing methods, producing large volumes of defect reports for features written before those tools became as useful. He also linked late discoveries to senior developers’ security-fix work during the ongoing “Vulnpocalypse” from April through the August PostgreSQL security release, which reduced normal beta-period review and testing. He said PostgreSQL’s broad feature interactions make exhaustive manual testing impractical and argued that LLM-assisted fuzzing should become part of feature development, alongside more robust internal interfaces. The community chose to preserve the release schedule rather than delay PostgreSQL 19 for additional fixes. Eisentraut expects many reverted features to return, while PostgreSQL 19 will retain features including REPACK CONCURRENTLY, logical replication of sequences, and planner hinting through pg_plan_advice.
Summary from peter.eisentraut.org.
Reports
One report so far. Additional coverage will appear here when it is linked to this story.
peter.eisentraut.org
The reverts will continue until morale improves
Read report →
Community reactions
Each reaction summarizes sampled comments from the linked discussion.
Hacker News · peter.eisentraut.org
Reported comments: 30 · 13 saved in sample
Analysis ready
Read this discussion’s reaction
Based on 13 sampled comments from this thread. Analyzed 2026-10-20.
The thread largely treats the PostgreSQL reversions as evidence of disciplined maintenance rather than failure: foundational infrastructure should shed unfinished features rather than gamble with users’ data and production stability. The AI angle enters through the suggestion that LLM-assisted review exposed edge cases, race conditions, and error paths that conventional review might have left dormant for years. Several readers see that as a valuable new quality lever: models can broaden test coverage, automate some review work, and help defenders find flaws before attackers using unrestricted models do. But the comments do not frame this as a triumph of AI-generated code. One reader explicitly stresses that the reverted work predates the current wave of AI coding tools, pushing back on any lazy vibe-coding diagnosis. The more uneasy reaction is that stronger LLM scrutiny may reveal a daunting number of plausible defects, turning every design decision into a larger research and verification exercise. Commenters recognize the irony: AI can help engineers write more robust code, yet it can also raise the standard of care so sharply that delivery slows. The prevailing view is still positive because the team chose stability over shipping, while the LLM discussion remains cautiously practical rather than promotional.
The main dispute is whether LLMs are simply a net quality multiplier or a source of an expanding verification burden. Supporters argue that automated review and testing uncover latent bugs early and are increasingly necessary against AI-assisted vulnerability hunting; skeptics worry that considering every newly surfaced edge case can consume the time needed to build anything at all.
- Praise: LLM-assisted review is being credited with surfacing obscure edge cases and failure states before they harden into years of production debt.
- Praise: Automated testing and code review offer maintainers a credible way to raise quality while developers learn where AI belongs in a serious release process.
- Praise: AI-aided vulnerability discovery makes earlier defensive scrutiny more urgent, especially when attackers can run less restricted models against mature codebases.
- Praise: Reverting features that cannot meet a demanding reliability bar shows the kind of stewardship critical infrastructure needs when deeper automated scrutiny finds trouble.
- Concern: More capable LLM review can turn every feature into a sprawling exercise in researching race conditions, error paths, and tradeoffs, slowing engineers under a higher bar.
- Concern: The volume of defects surfaced by AI-assisted analysis may exceed what maintainers can realistically resolve within a release cycle.
- Concern: Attributing the regressions to AI-generated or vibe-coded work is misleading here, since the affected code was written before those tools were available.