From: Greg Smith <gsmith@gregsmith.com>
To: Bill Moran <wmoran@collaborativefusion.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: Fri, 29 Aug 2008 12:15:17 -0400 (EDT)
Message-ID: <Pine.GSO.4.64.0808291156400.25234@westnet.com> (raw)
In-Reply-To: <20080829070852.0000022f.wmoran@collaborativefusion.com>
References: <BAY124-W57D3654AF1159CAF8EAC19F5660@phx.gbl>
<82bpze3ou8.fsf@mid.bfk.de>
<alpine.DEB.1.10.0808271436210.907@asgard.lang.hm>
<alpine.DEB.1.10.0808281411220.4454@aragorn.flymine.org>
<20080828095325.3c95f867.wmoran@collaborativefusion.com>
<Pine.GSO.4.64.0808290039180.23621@westnet.com>
<20080829070852.0000022f.wmoran@collaborativefusion.com>
On Fri, 29 Aug 2008, Bill Moran wrote:
> First off, the solution of making the postmaster immune to the OOM
> killer seems better than disabling overcommit to me anyway
I really side with Craig James here that the right thing to do here is to
turn off overcommit altogether. While it's possible that servers being
used for things other than PostgreSQL might need it, I feel that's a rare
case that's really hostile to the database environment and it shouldn't be
encouraged.
> I don't understand why we should avoid making the PG documentation as
> comprehensive as possible
The main problem here is that this whole area is a moving target. To
really document this properly, you end up going through this messy
exercise where you have to create a table showing what kernel versions
support the option you're trying to document. And even that varies based
on what distribution you're dealing with. Just because you know when
something showed up in the mainline kernel, without some research you
can't really know for sure when RedHat or SuSE slipped that into their
kernel--sometimes they lead mainline, sometimes they lag.
The PG documentation shies away from mentioning thing that are so
volatile, because the expectation is that people will still be using that
as a reference many years from now. For all we know, 2.6.27 will come out
and make any documentation about this obscure oomadj feature obsolete. I
think the only thing that might make sense here is to write something on
the Wiki that goes over in what situations you might run with overcommit
enabled, how that can interact with database operation, and then tries to
address the version issue. Then that can be updated as new versions are
released so it stays current. If that's available with a stable URL, it
might make sense to point to it in the documentation near where turning
overcommit off is mentioned.
--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
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: gsmith@gregsmith.com, wmoran@collaborativefusion.com
Subject: Re: select on 22 GB table causes "An I/O error occured while sending to the backend." exception
In-Reply-To: <Pine.GSO.4.64.0808291156400.25234@westnet.com>
* 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