Eisentraut argues the v18 cycle's uptick in post-commit reverts reflects a review process that is finally catching performance regressions, bad API shapes, and extension-breaking changes before release rather than letting them leak into shipped versions. He frames reverting master as a feature of a healthy project that treats itself as critical infrastructure, not an embarrassment to be minimized.
By submitting Eisentraut's post to HN where it reached 208 points, the submitter amplifies the thesis that visible reverts are evidence of rigor. The strong upvote signal from a developer-heavy audience suggests broad sympathy with the view that catching mistakes on master beats shipping them.
Eisentraut's post explicitly responds to a recurring complaint on the pgsql-hackers mailing list that frequent reverts make the project look chaotic, demoralize contributors who see their work pulled after weeks on master, and signal sloppiness. This is the position Eisentraut is pushing back against, but it is a real stance held within the community.
The editorial frames the revert debate through Postgres's unusual position: a mailing-list-driven open-source project that also underpins a double-digit percentage of production workloads. From that vantage, aggressive reverts on master are not optional hygiene but a necessary consequence of the stakes, aligning with Eisentraut while extending his argument to the project's structural context.
Peter Eisentraut — a longtime PostgreSQL core committer and release-management regular — published a post titled *The reverts will continue until morale improves*, a dry riff on the old sysadmin joke that lands differently when the person telling it has merge rights on one of the most-deployed databases on earth. The piece catalogs the uptick in post-commit reverts during the PostgreSQL 18 development cycle and makes a case that practitioners tend to miss: the revert rate isn't a sign the project is getting sloppier; it's a sign the review process is finally catching things that used to leak into releases.
The specifics matter. Eisentraut walks through examples from the v18 cycle where features landed on master, sat for days or weeks, and then were pulled — not because they were broken in a crash-the-server sense, but because performance regressions showed up on the buildfarm, because an API shape made downstream extensions unhappy, or because a committer who'd been traveling finally got time to read the thread and said *actually, no*. Async I/O refactors, a handful of planner heuristic changes, catalog representation tweaks, and some logical replication plumbing all show up in his list. None of them were small patches. Several had been in flight for more than one commitfest.
The tone of the post is unmistakably that of someone tired of defending the policy. The subtext is a response to a recurring complaint on pgsql-hackers that reverts are embarrassing, discourage contributors, and make the project look chaotic. Eisentraut's position is the opposite: a project that can't revert its own master branch is a project that ships its mistakes to production for you to find.
Postgres sits at an awkward spot in the software world. It is simultaneously a hobbyist-friendly open-source project with public mailing-list development *and* critical infrastructure for a double-digit percentage of production workloads on the planet. Those two identities pull the governance model in opposite directions. A hobbyist project wants to move fast and merge enthusiastically. Critical infrastructure wants a change-advisory board and a six-week freeze. Postgres has resolved the tension — not perfectly, but durably — by moving fast on master and then, when necessary, aggressively walking commits back before beta, before RC, and sometimes well into the stabilization window.
This is unusual among comparable projects. Most databases of Postgres's scale have moved to a model where the merge is the end of the review; Postgres treats the merge as the start of it. MySQL, SQLite, and the various proprietary engines all run review-before-merge pipelines where the commit itself is a near-irreversible event. Postgres runs more like the Linux kernel: things land on master, the buildfarm and the mailing list become the real integration test, and if the signal from either turns negative, the commit comes out. Eisentraut's point is that the second model only works if committers are psychologically willing to pull their own patches, and that willingness has to be modeled from the top or the pipeline silts up.
The comment threads on Hacker News and pgsql-hackers broke along predictable lines. One camp — mostly people who have run Postgres in production for ten-plus years — reads the revert rate as reassuring. Every revert on master is a bug that didn't ship to a customer's financial reporting pipeline at 2 a.m. The other camp — mostly contributors who've had their own patches reverted — argues that the process is demoralizing, that the signal to revert often arrives weeks after the commit when the author has moved on, and that reverting is cheap for the committer but expensive for the person whose six-month patch is now homework again. Both camps are correct. Eisentraut's post is essentially saying: the second cost is real, and we're still going to pay it, because the first cost is worse.
There is also a quieter technical story underneath the governance one. The specific features getting reverted in v18 cluster around *async I/O*, the planner, and *logical replication* — exactly the areas where Postgres has been trying to catch up to the workloads modern users actually run (NVMe-backed OLTP, large analytical queries alongside transactions, change-data-capture pipelines feeding Kafka). These are the hardest patches to land cleanly because they interact with every other subsystem, and they're the patches most likely to need a second or third attempt. A project that didn't allow reverts would either refuse those patches outright or ship them half-baked. Postgres is doing neither, and the revert count is the receipt.
If you run Postgres in production, the practical takeaway is counterintuitive but worth internalizing: the project's willingness to revert on master is one of the reasons point-release upgrades are as safe as they are. 18.1, 18.2, and 18.3 — whenever they land — will be built on a master branch that has already thrown out the patches that didn't survive contact with the buildfarm. The .0 release of a major Postgres version is usually fine; the .1 and .2 are almost always fine; the behavior that makes those releases boring is exactly the behavior Eisentraut is defending.
If you contribute to Postgres, or you contribute to any project that borrows Postgres's governance model (there are more than you'd think — pgvector, Citus, several forks), the operational advice is: budget for the revert. Treat getting your patch into master as the halfway point of the merge, not the end of it; subscribe to the buildfarm failures for the areas you touched; and don't take the eventual revert personally when it comes. The committers aren't rejecting the work. They're saying the signal from master wasn't clean enough and the clock is now against the release schedule. Rebasing and resubmitting into the next commitfest is the normal path, not a punishment.
For downstream vendors — the Supabase, Neon, Timescale, Crunchy Data, AWS RDS, Google AlloyDB tier — Eisentraut's post is also a quiet reminder that the base they build on is managed by humans who are willing to say no after already saying yes. That matters for how those vendors backport fixes and how they communicate about regressions. The reverts upstream are often the reason a managed Postgres can confidently track a .0 release within weeks instead of months.
The real test of the policy isn't the current cycle; it's whether the next generation of committers inherits the same ruthlessness. Postgres has an aging bench of senior committers and a steady trickle of new ones, and the cultural transmission of *it is okay to revert my own commit* is harder than the technical transmission of how the planner works. Eisentraut's post reads, in retrospect, less like a defense of v18 and more like documentation for the committers who'll be running v22. If they inherit the policy, Postgres stays boring in the best possible way. If they don't, the regressions start reaching your production — and you'll find out about them the hard way, at 2 a.m., on a quarter-end.
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.