ClickHouse measures strict memory overcommit turning a Postgres instance-wide OOM restart into one failed query at no measurable throughput cost

Sources: ClickHouse, discussion
Summary: The post, dated 2026-07-28 by Kaushik Iska, runs both kernel policies on one m7i.2xlarge with Postgres 16, a quarter of memory as huge pages behind a 6864MB shared_buffers, and a 3GB pgbench dataset. Under the default policy committed memory passed the reported 11.6GiB CommitLimit and reached 23.6GiB, the OOM killer took a backend holding 2.4GB, and because a SIGKILLed backend leaves the shared segment in an unknown state the postmaster terminated every backend and ran crash recovery, dropping all 20 bystander sessions and refusing new connections for 30.2 seconds. Under vm.overcommit_memory = 2 the tenth session got an out of memory error with 3.8GB still free, its transaction rolled back, and no session was dropped. Select-only throughput differed by 2.2 percent against a 4 to 5 percent run-to-run spread and read-write by 0.6 percent, with the arms interleaved and the read-write pass taken after warm-up. The commit limit formula is 80 percent of the memory left after the huge page reservation plus 2GB. This is a vendor post arguing for its own managed default.
Why it matters: The setting is one line of sysctl that any Postgres operator can apply and check, and it converts a whole-instance restart into a single failed query.