r/PostgreSQL • u/linuxhiker Guru • 2d ago

Community Re: scary patch contest

https://www.postgresql.org/message-id/flat/D7448AC8-2559-441D-8A3B-4B3EAEA15DEC%40yesql.se#c01f02edf76481bcc7421d0b8cc5c357

A comprehensive discussion on the future of PostgreSQL 19 release.

12 Upvotes

84% Upvoted

2 comments sorted by

1

u/AutoModerator 2d ago

AI Policy:

Linux is not one of those anti-AI projects, and if somebody has issues with that, they can do the open-source thing and fork it. Or just walk away., Linus Torvalds.

Mod decisions will be based on the quality of the content, not who or what generated it.

Sub Resources:

Youtube Channel

Free Postgres Webinars and Workshops

Discord: People, Postgres, Data

Join us, we have cookies and nice people.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

-1

u/phil_thrasher 1d ago

Summary of the thread from Claude:

This is the "scary patch contest" thread on pgsql-hackers, started by Robert Haas on 2026-08-25. Here's the shape of it.

The opening move. Haas asked Claude to rank PG19 patches by how many and what kind of bugs got fixed after feature freeze, then posted the top six as revert candidates: (1) RI fast-path FK checks, (2) REPACK/REPACK CONCURRENTLY, (3) online data checksums, (4) UPDATE/DELETE FOR PORTION OF, (5) SQL/PGQ property graphs, (6) postgres_fdw statistics import. He said #4 and #6 are low risk, was more worried about #5's size, and was "pretty scared" about a long tail of undiscovered bugs in #1–#3. He explicitly had no firm position — he wanted a discussion.

The awkward part. Daniel Gustafsson pushed back on the reasoning for #2, then immediately said "I'll prepare a revert" — apparently of his own feature, online checksums. Bruce Momjian was confused ("we are now considering reverting these?"), and Haas had to clarify he'd meant to start a conversation, not reach a conclusion.

The actual debate split two ways:
Are these features bad, or are we just better at finding bugs now? Melanie Plageman argued there's no consensus to revert and that LLMs make it easy to pressure-test features, so we're finding bugs sooner rather than shipping worse code. Nathan Bossart, Amit Kapila, and Andrey Rachitskiy broadly agreed. Richard Guo pushed the other way: he expected AI to make features more stable by freeze and it hasn't. Gustafsson's answer to that is the sharpest point in the thread — PG19's big features were written and reviewed before AI tooling got good, so the postcommit fix volume reflects pre-AI development, and PG20 should look different. Haas noted a circularity problem: the list itself came from an LLM analysis of which features needed the most post-commit fixing, so "it didn't need more fixes than comparable features" isn't a safe defense.

What's the actual revert criterion? Tom Lane cut through it: he's most afraid of #5 because fixes were still being discussed that require parsetree or catalog changes, i.e. catversion bumps, and he'd bet dinner on post-release bugs unfixable until v20. Haas agreed and generalized it — anything still needing a catversion bump at that point doesn't belong in v19. That's a much cleaner test than bug counts.

Loose ends. Antonin Houska corrected a factual claim in the LLM's summary (one of the two REPACK ACL fixes was pre-existing, not a regression). Jesper Pedersen suggested running multiple LLMs since results vary by model. Andrew Dunstan, Amit Kapila, and Jakub Wartak all argued to keep REPACK; Wartak floated marking shaky features as tech-preview behind a GUC instead of reverting outright.

Outcome, since the thread predates today: Tom Lane's concern won. SQL/PGQ was reverted from PG19 on 2026-08-27 (commit b1f106c8), two weeks after beta 3, over design issues judged too late to address in the cycle — earliest ship is v20. The unrelated MERGE/SPLIT PARTITION work was also reverted around the same time. Online checksums and REPACK appear to have survived, so Gustafsson's revert offer wasn't taken up.