Ubicloud says the Linux OOM killer can drop every Postgres connection at once. Its own co-founder says the post oversells it

The failure mode, and the one-line fix

.jpg)

Ubicloud's *PostgreSQL and the OOM killer* makes a specific claim: Postgres and the Linux OOM killer cannot safely coexist. The postmaster forks backends that share memory segments, so if the kernel kills one backend under pressure, shared memory may be left inconsistent — and the postmaster's only safe response is to terminate all backends, dropping every connection at once, or risk silent corruption.

Their fix is strict overcommit: vm.overcommit_memory=2, so the kernel refuses an over-limit allocation with ENOMEM up front, which Postgres handles gracefully by cancelling the one offending transaction instead of dying wholesale. They publish the CommitLimit they use — 80% of non-hugepage memory plus 2 GB — and, along the way, found a Linux 6.5 accounting bug that reported 651 GB committed on an 8 GB machine, fixed with a one-character change.

A correction, and a walk-back from the author's own company

The thread delivered a technical rebuttal and an unusually candid concession. First, the correction:

"Mode 0 (Heuristic) is described incorrectly. All this complex heuristic was removed almost a decade ago… The article ignores the proper modern solution … OOM Score Adjust." — a commenter naming the omitted alternative

Then the co-founder of the company that published the post appeared to temper its own headline:

"I agree with the blog post's technical contents, but I feel we came across too strong in the title… I can see many other scenarios, where using strict memory overcommit would have unanticipated side-effects." — Ozgun of Ubicloud, ex-Citus Data

A systems commenter argued the real fix lives in the application, not a kernel knob:

"The proper way to handle OOM is to do what mature databases do: implement your own memory accounting, use only your own allocators… ensure that every allocation path can recover from OOM." — a commenter on application-level memory discipline

And a practical hazard the post underplays: on some setups, strict overcommit can start blocking `fork()` itself — test it in staging before you ship it to production. The usable takeaway is narrower than the title: overcommit_memory=2 is a sound default for a dedicated Postgres box, but it's a tuning trade-off with sharp edges, not the universal cure the headline implies — and the people who wrote it will tell you so.