Received: from localhost (unknown [200.46.204.183])
	by postgresql.org (Postfix) with ESMTP id 2616C64FCE7
	for <pgsql-performance-postgresql.org@postgresql.org>;
	Thu, 28 Aug 2008 01:37:06 -0300 (ADT)
Received: from postgresql.org ([200.46.204.86])
	by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024)
	with ESMTP id 34210-07 for
	<pgsql-performance-postgresql.org@postgresql.org>;
	Thu, 28 Aug 2008 01:36:38 -0300 (ADT)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130])
	by postgresql.org (Postfix) with ESMTP id 9BF1C64FCD6
	for <pgsql-performance@postgresql.org>;
	Thu, 28 Aug 2008 01:35:13 -0300 (ADT)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
	by sss.pgh.pa.us (8.14.2/8.14.2) with ESMTP id m7S4Z7I0000358;
	Thu, 28 Aug 2008 00:35:07 -0400 (EDT)
To: Alvaro Herrera <alvherre@commandprompt.com>
cc: david@lang.hm, Andrew Sullivan <ajs@commandprompt.com>,
	pgsql-performance@postgresql.org
Subject: Re: select on 22 GB table causes "An I/O error occured while sending
	to the backend." exception
In-reply-to: <20080828021952.GH4071@alvh.no-ip.org> 
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>
	<20080828021952.GH4071@alvh.no-ip.org>
Comments: In-reply-to Alvaro Herrera <alvherre@commandprompt.com>
	message dated "Wed, 27 Aug 2008 22:19:52 -0400"
Date: Thu, 28 Aug 2008 00:35:07 -0400
Message-ID: <357.1219898107@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests=none
X-Spam-Level: 
X-Archive-Number: 200808/361
X-Sequence-Number: 31242

Alvaro Herrera <alvherre@commandprompt.com> writes:
> Some time ago I found that it was possible to fiddle with a /proc entry
> to convince the OOM to not touch the postmaster.  A postmaster with the
> raw IO capability bit set would be skipped by the OOM too killer (this
> is an Oracle tweak AFAIK).
> These are tricks that people could use in their init scripts to protect
> themselves.

Yeah?  Details please?  Does the bit get inherited by child processes?

> (I wonder if the initscript supplied by the RPMs or Debian should
> contain such a hack.)

It would certainly make sense for my RHEL/Fedora-specific packages,
since those are targeting a very limited range of kernel versions.
Not sure about the situation for other distros.

			regards, tom lane