Especially with containers around you might very well hit the case of running new kernel but older version of PostgreSQL with no code mitigation for the problem
I can defend someone who is unwilling to yield on quality. Afterall, this truly is his baby. Issuing scathing rebukes to well-intentioned contributors is like slapping my kid when he brings me the wrong type of screwdriver.
You don't talk like this to junior or even senior engineers, but you do reach a level at which gently telling isn't necessary.
If you don't like it go fork Linux and try being the nice benevolent dictator and we'll applaud your success.
You might have transparent huge pages on by default depending on the distro
The headline implies it broke PG everywhere. It didn’t.
Since we will never know it might be a good idea to feature gate the change, change the default and let users decide to change it back. This may give some feedback on the lkml or else to decide if the change is worthwhile?
It's very close to a real world simulation of a production workload
Also a crime that people are still running databases with 4kb pages.
To put it in perspective, this means you will have more than 30 million pages on a server with 128GB RAM. As an example, if there is 16bytes of metadata for memory page. The metadata itself would take more than half a gigabyte.
Doing research though a spinlock actually doesn't seem as unusual a hack as it would first seem, do drivers and the like not have similar issues because they don't trigger a page fault I guess?
selckin•1h ago