July 10, 2026
Kernel Panic! Or Just Panic?
Preempt_none Is Dead; Your Postgres Probably Doesn't Care
That scary slowdown headline sent people spiraling, but most Postgres users can relax
TLDR: A benchmark made it look like a new Linux release crippled PostgreSQL, but the article says the slowdown came from a narrow, badly tuned test that most users won’t hit. The community reaction swung between panic, skepticism, and outright mockery, with some treating it as overhyped benchmark drama.
The internet saw a big scary benchmark saying a new Linux version made PostgreSQL — the database that quietly powers huge chunks of the web — run at about half speed, and naturally people went into full panic mode. The article says clients were suddenly asking if they should freeze updates, while sites like Hacker News did their usual thing: turn one alarming chart into an existential crisis. But the author’s actual message is way less apocalyptic: this wasn’t Linux suddenly wrecking databases for everyone. It was a very specific, very noisy lab setup that exposed a problem most normal users are unlikely to hit.
That’s where the community mood gets spicy. On one side: the headline doomers, acting like every server admin should barricade the doors and cancel upgrades immediately. On the other: the eye-rollers, basically saying, “Congrats, you created a benchmark that proves bad settings are bad.” The funniest drive-by reaction came from commenter Gigachad, who didn’t even bother arguing the tech and simply sneered, “Looks like an AI spam blog.” Brutal. That one-liner basically became the social vibe in miniature: less calm technical debate, more internet snark, suspicion, and instant dismissal.
The real twist is that the article turns the panic into a ‘nothingburger for most people’ story. Yes, the slowdown was real. No, your average Postgres setup probably doesn’t care. And the comments? They’re the real show: half meltdown, half mockery, with a side of “please stop making everyone panic with benchmark theater.”
Key Points
- •The article says the reported PostgreSQL slowdown on Linux 7.0 is real but specific to a narrow benchmark configuration rather than a broad reason to delay kernel upgrades.
- •It attributes the benchmark result to Linux 7.0 removing PREEMPT_NONE on several architectures and shifting typical defaults toward PREEMPT_LAZY.
- •The AWS benchmark used a 96-vCPU Graviton4 m8g.24xlarge system, PostgreSQL 17, pgbench simple-update, and a linux-next kernel snapshot.
- •In the reported results, the PREEMPT_LAZY baseline achieved 50,751.96 while reverting commit 7dadeaa6e851 increased throughput to 98,565.86, about 1.94x.
- •perf data in the article shows most of the lost CPU time concentrated in PostgreSQL’s userspace spinlock s_lock within the GetVictimBuffer path.