April 29, 2026
Kernel panic? More like comment panic
Linux 7.0 Broke PostgreSQL: The Preemption Regression Explained
A Linux update sent database fans into meltdown and the comments got even messier
TLDR: A Linux 7.0 change made PostgreSQL run about half as fast in one huge stress test, raising real worries for high-end servers. But commenters fought harder over the write-up itself — saying the headline exaggerated, the explanation was shaky, and parts looked suspiciously borrowed.
A fresh Linux update was supposed to keep big servers humming along, but one engineer found that on a giant Amazon chip, PostgreSQL — the database software behind loads of websites and apps — suddenly dropped from about 98,000 actions a second to roughly 50,000. That’s the kind of chart that makes server admins spill their coffee. The article blames a change in how Linux decides when to pause one task and let another run, which turned a tiny waiting point inside PostgreSQL into an absolute traffic jam.
But in the comments, the real fireworks started. One camp basically yelled, "this headline is overselling it", with critics saying Linux 7.0 did not "break PostgreSQL everywhere," only in a very specific, extreme setup. Another group went full fact-check mode, arguing the post muddled the explanation and mixed up what the Linux setting actually does. And then came the academic-drama twist: one reader accused the write-up of getting a little too cozy with another blog post, saying parts felt way too similar.
The funniest energy, though, came from the performance snobs. One commenter called it a "crime" that PostgreSQL still can’t easily use giant memory pages in 2026, while another basically suggested the whole thing was a niche benchmark panic dressed up as a global disaster. So yes, the bug is real — but the comment section turned it into a delicious mix of nitpicking, outrage, and nerd-on-nerd scandal.
Key Points
- •AWS engineer Salvatore Dipietro reported a PostgreSQL performance regression on Linux 7.0 after benchmarking a 96-vCPU Graviton4 system.
- •In the cited pgbench test, Linux 6.x achieved 98,565 transactions per second versus 50,751 transactions per second on Linux 7.0.
- •perf profiling showed about 55% of CPU time spent in PostgreSQL’s s_lock path during the affected workload.
- •The article says Linux 7.0 removed PREEMPT_NONE on modern CPU architectures, leaving PREEMPT_FULL and PREEMPT_LAZY.
- •The article explains PostgreSQL’s 8 KB page-based storage and shared buffer pool as key context for why the scheduling change exposed a severe case.