kernel maintainers are pushing the fix burden onto PostgreSQL
Maybe it isn’t applicable in this context, but didn’t Linus Torvalds send an angry email on an adjacent topic, but regarding the same philosophy?
Found it: we do not break userspace
Disclaimer: I am a noob when it comes to Linux and building operating systems.
Well, technically, it’s not broken, just slower
Regardless of Linus’s philosophy, such a change in Postgresql would need to be backported to previous versions, because migrating from one major release to another is far from being straightforward.
Wouldn’t it make sense to merge in rseq support well in advance of removing PREEMPT_NONE, not do both at the same time?
But that hurts the ego of the kernel developer because they have to wait for the next release.
sounds like rseq has been around since 2018 https://www.phoronix.com/news/Restartable-Sequences-Speed
I think it’s a bit weird that postgres hasn’t done any testing on the new kernel. That’s something I would kinda expect from a major database. The fact this was only found in production is a bit … weird.
Why would they? The current stable kernel release is still v6.19
Because that’s what you do with important software? You don’t want to stack up potential issues until the final release for the public.
I’ll be curious to see benchmarks of PREEMPT_NONE vs rseq once PostgreSQL patches this
Which is expected to be faster in the end?
This has been known for awhile, and this was already accepted to be an issue with PH memory handling. Not weird, rare or otherwise, it will get fixed.
Maybe Linux is considering prioritizing consumer hardware (safety, less room for human error)? Android is already a thing, so maybe there is pressure for prioritizing consumer hardware?
