Earlier quoted context omitted.
There was also a bug in the Linux kernel, or did I miss something?
Yes there was. It's detailed in the article.
PostgreSQL and the OOM killer: Why we use strict memory overcommit
71–80 of 140 posts
Re: PostgreSQL and the OOM killer: Why we use strict memory overcommit
#72Earlier quoted context omitted.
That doesn't really explain why it is a footgun.
The last paragraph: > On the modern desktop, where programmers don't care about failing malloc(), disabling overcommit is shooting yourself in the foot. As you can observe, the memory allocations start failing long before the memory is exhausted.
Re: PostgreSQL and the OOM killer: Why we use strict memory overcommit
#73The problem with disabling the memory overcommit is that then the RAM is wasted. That can be worked around with setting up swap but then the disk space is wasted.
Re: PostgreSQL and the OOM killer: Why we use strict memory overcommit
#74Earlier quoted context omitted.
The last paragraph: > On the modern desktop, where programmers don't care about failing malloc(), disabling overcommit is shooting yourself in the foot. As you can observe, the memory allocations start failing long before the memory is exhausted.
So it's a footgun because a lot of low quality software?
Re: PostgreSQL and the OOM killer: Why we use strict memory overcommit
#75Re: PostgreSQL and the OOM killer: Why we use strict memory overcommit
#76Re: PostgreSQL and the OOM killer: Why we use strict memory overcommit
#77Earlier quoted context omitted.
Is Firefox low quality?
Well, if Firefox also works on other OSes, it probably should gracefully handle failing allocations, isn't it?
Re: PostgreSQL and the OOM killer: Why we use strict memory overcommit
#78Earlier quoted context omitted.
> Typically, performance drops enough that the user kills the program or reboots before the page file expands to fill the disk. And other threads here suggest there is something that will prompt users to kill programs in states like this. Not in the age of NVMe it doesn't. Swap is fast now. Plus, at least on Linux, you can put zswap in front of the regular swap and introduce an even faster level of memory hierarchy a…
Windows does memory compression too.
Re: PostgreSQL and the OOM killer: Why we use strict memory overcommit
#79Earlier quoted context omitted.
Yes there was. It's detailed in the article.
But why wouldn't have happened with Rust? Sorry I can't find anything about Rust in the article. Or you mean if the Linux kernel was written in Rust and that stupid bool coercion was not possible?
Though to be absolutely pedantic, !x is an int for x:int in C, there is no bool coercion involved; an if-statement takes an expression of any scalar value and evals to true on non-zero. Not that that helps to avoid introducing bugs anyway.
Re: PostgreSQL and the OOM killer: Why we use strict memory overcommit
#80Linux vm defaults are legit insane in 2026. - system dies under memory pressure (regardless of swapping, actually not having swap makes it worse which should be common knowledge by now) - system dies under disk pressure even if there are tons of free memory (this one is fun to diagnose) - system can technically not die, but render itself useless (or worse) under memory pressure by the oom killer - memory compression…