A better bug finder does not mean the code got worse. It means you can finally see the bottle caps from 1987, and someone still has to decide which ones to dig up before lunch.

That is the lesson. Detection got cheap. Judgment did not. A release calendar that pretends those two speeds match will slip, or it will ship a fix that should never have been committed.

PostgreSQL major releases have been boring for a decade, in the good way: no earlier than mid-September, no later than mid-October. This year broke the pattern. Robert Haas wrote that version 19 will most likely wait until November, and might wait longer. Three large features came out between August 27 and September 15, deep in beta: UPDATE/DELETE FOR PORTION OF, SQL Property Graph Queries, and partition merge/split. Yanking a big feature right after the April feature freeze is ordinary. Yanking several of them at the end of summer is not.

The interesting part is where the extra work went. Haas compared April 8 through September 25. In 2025, master got 1,037 commits and the stable branch for the release then in progress got 724. In 2026 those numbers were 1,443 and 1,169. Commits that landed only on master declined slightly. Back-patched commits jumped by more than 60 percent. The previous stable branch did the same thing: 248 commits in that window last year, 433 this year, more than 74 percent. The committers did not suddenly get careless. A lot more people are pointing language models at a codebase whose history runs past thirty years, and filing what those models surface. Drafting a patch got easier. Reviewing one did not. The people allowed to commit still have the same number of hours.

Treat it as a queue, because it is one.

Findings per week are the arrival rate. Reviewed fixes that meet the project's own rules are the service rate. For a long time those rates were close enough that the train left on time. Then arrivals jumped, and service did not. A model can propose a patch in a closed loop: read the code, write a test, see if it fails. You can run that loop all night. The internet currently is. The loop that ships is open. It ends at a person who knows whether the patch is right, whether it belongs on every supported version, and whether the cure is worse than the bug. Haas is plain that model-written fixes are often wrong, or right in a way Postgres will not accept.

That is why the date moved. Hours that were supposed to answer "is this feature ready?" went to security issues and older bugs that had just become visible. Near a release, an unanswered question about a large feature has one responsible answer: take it out. Do that three times and you are off the old calendar. The delay is what quality looks like when inspection outruns repair. It is not proof that the code rotted in a single summer.

You have already seen the small version. Turn on a fuzzer, a sanitizer, or a stricter linter and the bug count spikes that week. Nobody rewrote the module overnight. You changed the sensor. If "bugs opened" is your quality score, you will scold the team for buying a better sensor, and someone will turn the sensor down until the chart behaves.

Don't do this: feed every new report to an agent and merge whatever comes back with a green test. Finding scales. Judgment does not. Plenty of defects in a system this old sit on extreme edges, and the tidy fix deletes a feature or spends a performance budget you do not have. A patch that compiles is not a patch you understand. In a database, the difference is someone's data.

Tomorrow, before you enable the new finder, write two numbers where the team will see them. How many findings a week a human can actually close. What gets dropped when the queue passes that. Drop scope. Keep the security work. Split the chart in two: bugs introduced after the cutoff, and bugs discovered after the cutoff. One series tells you if new code is getting worse. The other tells you the flashlight works. Keep only one series and the retro becomes an argument about a failure that never happened.

Point the finder at the oldest code your users still run. That is the buried layer. Budget the digging before you announce the count.

Source: Postgres 19 is late, and it's AI's fault

Discussion: Hacker News

This post was generated automatically from public Hacker News data.