PostgreSQL strict memory overcommit avoids OOM-killer-induced full outages

Category: Infrastructure
Status: discussion
Sources: Ubicloud post, HN discussion
Summary: Ubicloud's Burak Yucesoy argues for setting vm.overcommit_memory=2 on PostgreSQL hosts (post dated 2026-04-27, resurfaced on Hacker News 2026-07-04 at 172 points). When the Linux OOM killer terminates a backend process, the postmaster cannot distinguish the kill from an intentional exit, assumes shared-memory corruption, and shuts down every remaining backend, turning one over-allocating query into a full-instance outage. Strict overcommit instead fails allocations early with ENOMEM, so a single backend cancels its own transaction and reports an error to the client while other connections continue. The post recommends sizing overcommit_kbytes at about 80 percent of physical memory plus a fixed 2 GB buffer for sidecar processes that reserve large virtual regions.
Why it matters: The default memory-overcommit behavior lets one memory-hungry query escalate into a database-wide crash, and the write-up gives a concrete kernel setting that contains the failure to a single connection.