Received: from localhost (unknown [200.46.204.184]) by postgresql.org (Postfix) with ESMTP id 16A822E348E for ; Tue, 11 Dec 2007 06:26:16 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.184]) (amavisd-maia, port 10024) with ESMTP id 40537-09 for ; Tue, 11 Dec 2007 06:26:06 -0400 (AST) Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by postgresql.org (Postfix) with ESMTP id E8E902E346B for ; Tue, 11 Dec 2007 06:26:11 -0400 (AST) Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) id 1J22JR-0005qw-JY; Tue, 11 Dec 2007 11:26:05 +0100 Received: from fweimer by bfk.de with local id 1J22JR-0002tz-HP; Tue, 11 Dec 2007 11:26:05 +0100 To: Andrew Sullivan Cc: pgsql-admin@postgresql.org Subject: Re: Dangerous hint in the PostgreSQL manual References: <20071210162612.a9y113hzjkookooc@webmail.kwsoft.de> <20071210204750.GA22340@crankycanuck.ca> From: Florian Weimer Date: Tue, 11 Dec 2007 11:26:05 +0100 In-Reply-To: <20071210204750.GA22340@crankycanuck.ca> (Andrew Sullivan's message of "Mon, 10 Dec 2007 15:47:50 -0500") Message-ID: <824pepr0hu.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200712/48 X-Sequence-Number: 27565 * Andrew Sullivan: > You _want_ the fork to fail when the kernel can't (over)commit the > memory, because otherwise the stupid genius kernel will come along > and maybe blip your postmaster on the head, causing it to die by > surprise. The other side of the story is that with overcommit, the machine continues to work flawlessly in some loads, when it would fail without overcommit. It's also not clear that trading a segfault for malloc returning a null pointer leads to more deterministic failures (because the malloc failure does not necessarily occur in the memory hog). My personal experience is that vm.overcommit_memory=3D2 (together with tons of swap space) leads to more deterministic failure behavior, but we don't use much software that aggressively allocates address space without actually using it (Sun's JVM does in some cases, and SBCL is particularly obnoxious in this regard). --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99