From: Jeff Davis <pgsql@j-davis.com>
To: david@lang.hm
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andrew Sullivan <ajs@commandprompt.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: select on 22 GB table causes "An I/O error occured while sending to the backend." exception
Date: Thu, 28 Aug 2008 11:07:18 -0700
Message-ID: <1219946838.22237.26.camel@jdavis> (raw)
In-Reply-To: <alpine.DEB.1.10.0808272316310.30743@asgard.lang.hm>
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>
<alpine.DEB.1.10.0808272316310.30743@asgard.lang.hm>
On Wed, 2008-08-27 at 23:23 -0700, david@lang.hm wrote:
> there are periodic flamefests on the kernel mailing list over the OOM
> killer, if you can propose a better algorithm for it to use than the
> current one that doesn't end up being just as bad for some other workload
> the kernel policy can be changed.
>
Tried that: http://lkml.org/lkml/2007/2/9/275
All they have to do is *not* count shared memory against the process (or
at least not count it against the parent of the process), and the system
may approximate sanity.
> IIRC the reason why it targets the parent process is to deal with a
> fork-bomb type of failure where a program doesn't use much memory itself,
> but forks off memory hogs as quickly as it can. if the OOM killer only
> kills the children the problem never gets solved.
But killing a process won't free shared memory. And there is already a
system-wide limit on shared memory. So what's the point of such a bad
design?
Regards,
Jeff Davis
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: pgsql@j-davis.com, david@lang.hm, tgl@sss.pgh.pa.us, ajs@commandprompt.com
Subject: Re: select on 22 GB table causes "An I/O error occured while sending to the backend." exception
In-Reply-To: <1219946838.22237.26.camel@jdavis>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox