DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
	h=message-id:date:from:to:subject:cc:in-reply-to:mime-version
	:content-type:content-transfer-encoding:content-disposition
	:references;
	b=QAO9sw6RgDC65HnlQNwmWZxM60wpUTosGfYaI6Zv2qVmsu+eG308Yk7f+5dUNydhV7
	bHqi5d6yuM5laurOspuVRXe+A0gm/4oCHXsoZeQrw25z3C0wk5m8Xrew7NKW6SIq4cRG
	4A2uWJ8k9wU4aRUt9HxUDTAPOh7wkaeCkdk0k=
Message-ID: <dcc563d10808281811t5c98dcaexd98c5cfe679f428d@mail.gmail.com>
Date: Thu, 28 Aug 2008 19:11:50 -0600
From: "Scott Marlowe" <scott.marlowe@gmail.com>
To: david@lang.hm
Subject: Re: select on 22 GB table causes "An I/O error occured while sending
	to the backend." exception
Cc: "Matthew Wakeling" <matthew@flymine.org>,
	"PostgreSQL Performance" <pgsql-performance@postgresql.org>
In-Reply-To: <alpine.DEB.1.10.0808281602460.2713@asgard.lang.hm>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
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>
	<EADBB336-A14E-492C-A8CA-105C8F77A43A@blighty.com>
	<alpine.DEB.1.10.0808281702450.4454@aragorn.flymine.org>
	<48B6EA7E.2090707@emolecules.com>
	<alpine.DEB.1.10.0808282110140.4454@aragorn.flymine.org>
	<dcc563d10808281542u383808bci4874713a31bd1cc6@mail.gmail.com>
	<alpine.DEB.1.10.0808281602460.2713@asgard.lang.hm>

On Thu, Aug 28, 2008 at 5:08 PM,  <david@lang.hm> wrote:
> On Thu, 28 Aug 2008, Scott Marlowe wrote:
>
>> On Thu, Aug 28, 2008 at 2:29 PM, Matthew Wakeling <matthew@flymine.org>
>> wrote:
>>
>>> Another point is that from a business perspective, a database that has
>>> stopped responding is equally bad regardless of whether that is because
>>> the
>>> OOM killer has appeared or because the machine is thrashing. In both
>>> cases,
>>> there is a maximum throughput that the machine can handle, and if
>>> requests
>>> appear quicker than that the system will collapse, especially if the
>>> requests start timing out and being retried.
>>
>> But there's a HUGE difference between a machine that has bogged down
>> under load so badly that you have to reset it and a machine that's had
>> the postmaster slaughtered by the OOM killer.  In the first situation,
>> while the machine is unresponsive, it should come right back up with a
>> coherent database after the restart.
>>
>> OTOH, a machine with a dead postmaster is far more likely to have a
>> corrupted database when it gets restarted.
>
> wait a min here, postgres is supposed to be able to survive a complete box
> failure without corrupting the database, if killing a process can corrupt
> the database it sounds like a major problem.

Yes it is a major problem, but not with postgresql.  It's a major
problem with the linux OOM killer killing processes that should not be
killed.

Would it be postgresql's fault if it corrupted data because my machine
had bad memory?  Or a bad hard drive?  This is the same kind of
failure.  The postmaster should never be killed.  It's the one thing
holding it all together.