I’ll be curious to see benchmarks of PREEMPT_NONE vs rseq once PostgreSQL patches this
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?
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
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.
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.
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.
Well, technically, it’s not broken, just slower
Wouldn’t it make sense to merge in rseq support well in advance of removing PREEMPT_NONE, not do both at the same time?
sounds like rseq has been around since 2018 https://www.phoronix.com/news/Restartable-Sequences-Speed
But that hurts the ego of the kernel developer because they have to wait for the next release.
