Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Linux 7.0 Broke PostgreSQL: The Preemption Regression Explained

read.thecoder.cafe

Post reply on HN
Print view View original

11–20 of 73 posts

Re: Linux 7.0 Broke PostgreSQL: The Preemption Regression Explained

#11

Post by ecshafer »

nobleach wrote: post #6
PunchyHamster wrote: post #3

Seems Linus needs to yell at someone again. 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 get that folks love a good Linus rant. But as someone who's been at the end of that style of "feedback", nothing can be more humiliating or demotivating. Certainly there are contributors that are making "rookie mistakes". There are folks that aren't willing to ingest the entire context of what was tried back in 2.0.36, 2.2, 2.4... etc. And perhaps it's wise to simply stay away until you're completely certain you've…

I don't think a Linus rant ever hit anyone that was a rookie, they are always AFAIK against people "who should know better". Veteran developers, with multiple commits merged.

Re: Linux 7.0 Broke PostgreSQL: The Preemption Regression Explained

#12

Post by dist-epoch »

baq wrote: post #4

TLDR of the LMKL thread: 120GB RAM postgres with hugepages=off, lock contention went from terrible to abysmal. nothing to see here except that amazon for whatever reason runs DB tests with huge pages disabled. (hope I'm not paying for RDS and auroras like that in production!)

Many people have desktops with 128 GB RAM. Should they enable hugepages? I've never heard this recommendation for a desktop.

Re: Linux 7.0 Broke PostgreSQL: The Preemption Regression Explained

#13

Post by nijave »

baq wrote: post #4

TLDR of the LMKL thread: 120GB RAM postgres with hugepages=off, lock contention went from terrible to abysmal. nothing to see here except that amazon for whatever reason runs DB tests with huge pages disabled. (hope I'm not paying for RDS and auroras like that in production!)

In fairness, AWS could (and almost certainly is) using their own kernel build that does who-knows-what

Re: Linux 7.0 Broke PostgreSQL: The Preemption Regression Explained

#15

Post by nijave »

dist-epoch wrote: post #12
baq wrote: post #4

TLDR of the LMKL thread: 120GB RAM postgres with hugepages=off, lock contention went from terrible to abysmal. nothing to see here except that amazon for whatever reason runs DB tests with huge pages disabled. (hope I'm not paying for RDS and auroras like that in production!)

Many people have desktops with 128 GB RAM. Should they enable hugepages? I've never heard this recommendation for a desktop.

Huge pages is good when a single process is reserving a giant block of memory which I think isnt that common.

You might have transparent huge pages on by default depending on the distro

Re: Linux 7.0 Broke PostgreSQL: The Preemption Regression Explained

#16

Post by colechristensen »

nobleach wrote: post #6
PunchyHamster wrote: post #3

Seems Linus needs to yell at someone again. 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 get that folks love a good Linus rant. But as someone who's been at the end of that style of "feedback", nothing can be more humiliating or demotivating. Certainly there are contributors that are making "rookie mistakes". There are folks that aren't willing to ingest the entire context of what was tried back in 2.0.36, 2.2, 2.4... etc. And perhaps it's wise to simply stay away until you're completely certain you've…

If you're at the level of delivering to Linus, I'm sorry but humiliation and demotivation are earned.

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.

Re: Linux 7.0 Broke PostgreSQL: The Preemption Regression Explained

#17

Post by buster »

I'd rather like to know if any real world usage broke, before coming to the conclusion that an edge case synthetic benchmark is worth changing the kernel (back or wherever) where supposedly the change that broke the benchmark had real world benefits.

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?

Re: Linux 7.0 Broke PostgreSQL: The Preemption Regression Explained

#18

Post by nijave »

buster wrote: post #17

I'd rather like to know if any real world usage broke, before coming to the conclusion that an edge case synthetic benchmark is worth changing the kernel (back or wherever) where supposedly the change that broke the benchmark had real world benefits. 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 th…

"synthetic benchmark" is doing some heavy lifting here. Pgbench just runs a bunch of SQL statements against a real Postgres instance.

It's very close to a real world simulation of a production workload

Re: Linux 7.0 Broke PostgreSQL: The Preemption Regression Explained

#19

Post by ameliaquining »

This post comes uncomfortably close to plagiarizing https://thebuild.com/blog/2026/04/23/preempt_none-is-dead-yo..., which it cites as a source; almost all the technical explanation is in there and some of the wording is extremely similar. Compare, e.g., "What Linux 7.0 actually changed" in Pettus's post to "What Is Preemption?" in this one. I think this link should have been to Pettus's post instead.

Re: Linux 7.0 Broke PostgreSQL: The Preemption Regression Explained

#20

Post by ozgrakkurt »

It is a crime that postgres isn't able to allocate with 1GB huge pages by changing a config parameter in 2026

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.

Post reply on HN