Message-ID: <48B63E9B.4030603@emolecules.com>
Date: Wed, 27 Aug 2008 22:58:51 -0700
From: Craig James <craig_james@emolecules.com>
User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707)
MIME-Version: 1.0
To: pgsql-performance@postgresql.org
Subject: Re: select on 22 GB table causes "An I/O error occured
	while sending to the backend." exception
References: <BAY124-W57D3654AF1159CAF8EAC19F5660@phx.gbl>
	<82bpze3ou8.fsf@mid.bfk.de>
	<alpine.DEB.1.10.0808271436210.907@asgard.lang.hm>
	<20080827221338.GP18946@commandprompt.com>
	<alpine.DEB.1.10.0808271516300.907@asgard.lang.hm>
	<659.1219899383@sss.pgh.pa.us>
In-Reply-To: <659.1219899383@sss.pgh.pa.us>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

The OOM killer is a terrible idea for any serious database server.  I wrote a detailed technical paper on this almost 15 years ago when Silicon Graphics had this same feature, and Oracle and other critical server processes couldn't be made reliable.

The problem with "overallocating memory" as Linux does by default is that EVERY application, no matter how well designed and written, becomes unreliable: It can be killed because of some OTHER process.  You can be as clever as you like, and do all the QA possible, and demonstrate that there isn't a single bug in Postgres, and it will STILL be unreliable if you run it on a Linux system that allows overcommitted memory.

IMHO, all Postgres servers should run with memory-overcommit disabled.  On Linux, that means  /proc/sys/vm/overcommit_memory=2.

Craig