From: Tom Lane <tgl@sss.pgh.pa.us>
To: david@lang.hm
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 00:56:23 -0400
Message-ID: <659.1219899383@sss.pgh.pa.us> (raw)
In-Reply-To: <alpine.DEB.1.10.0808271516300.907@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>
david@lang.hm writes:
> On Wed, 27 Aug 2008, Andrew Sullivan wrote:
>> The upshot of this is that postgres tends to be a big target for the
>> OOM killer, with seriously bad effects to your database. So for good
>> Postgres operation, you want to run on a machine with the OOM killer
>> disabled.
> I disagree with you.
Actually, the problem with Linux' OOM killer is that it
*disproportionately targets the PG postmaster*, on the basis not of
memory that the postmaster is using but of memory its child processes
are using. This was discussed in the PG archives a few months ago;
I'm too lazy to search for the link right now, but the details and links
to confirming kernel documentation are in our archives.
This is one hundred percent antithetical to the basic design philosophy
of Postgres, which is that no matter how badly the child processes screw
up, the postmaster should live to fight another day. The postmaster
basically exists to restart things after children die ungracefully.
If the OOM killer takes out the postmaster itself (rather than the child
that was actually eating the unreasonable amount of memory), we have no
chance of recovering.
So, if you want a PG installation that is as robust as it's designed to
be, you *will* turn off Linux' OOM killer. Otherwise, don't complain to
us when your database unexpectedly stops responding.
(Alternatively, if you know how an unprivileged userland process can
defend itself against such exceedingly brain-dead kernel policy, we are
all ears.)
regards, tom lane
PS: I think this is probably unrelated to the OP's problem, since he
stated there was no sign of any problem from the database server's
side.
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: tgl@sss.pgh.pa.us, david@lang.hm, 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: <659.1219899383@sss.pgh.pa.us>
* 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