From: Scott Marlowe <scott.marlowe@gmail.com>
To: david@lang.hm
Cc: Matthew Wakeling <matthew@flymine.org>
Cc: PostgreSQL Performance <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 19:11:50 -0600
Message-ID: <dcc563d10808281811t5c98dcaexd98c5cfe679f428d@mail.gmail.com> (raw)
In-Reply-To: <alpine.DEB.1.10.0808281602460.2713@asgard.lang.hm>
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.
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: scott.marlowe@gmail.com, david@lang.hm, matthew@flymine.org
Subject: Re: select on 22 GB table causes "An I/O error occured while sending to the backend." exception
In-Reply-To: <dcc563d10808281811t5c98dcaexd98c5cfe679f428d@mail.gmail.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