From: Magnus Hagander <magnus@hagander.net>
To: david@lang.hm
Cc: Scott Marlowe <scott.marlowe@gmail.com>
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: Fri, 29 Aug 2008 10:00:42 +0200
Message-ID: <48B7ACAA.7060800@hagander.net> (raw)
In-Reply-To: <alpine.DEB.1.10.0808281814100.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>
<dcc563d10808281811t5c98dcaexd98c5cfe679f428d@mail.gmail.com>
<alpine.DEB.1.10.0808281814100.2713@asgard.lang.hm>
david@lang.hm wrote:
> On Thu, 28 Aug 2008, Scott Marlowe wrote:
>>> 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.
>
> the ACID guarantees that postgres is making are supposed to mean that
> even if the machine dies, the CPU goes up in smoke, etc, the
> transactions that are completed will not be corrupted.
>
> if killing the process voids all the ACID protection then something is
> seriously wrong.
>
> it may loose transactions that are in flight, but it should not corrupt
> the database.
AFAIK, it's not the killing of the postmaster that's the problem. The
backends will continue running and *not* corrupt anything, because the
shared memory and locking sicks around between them.
The issue is if you manage to start a *new* postmaster against the same
data directory. But there's a whole bunch of safeguards against that, so
it certainly shouldn't be something you manage to do by mistake.
I may end up being corrected by someone who knows more, but that's how
I've understood it works. Meaning it is safe against OOM killer, except
it requires manual work to come back up. But it shouldn't corrupt your data.
//Magnus
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: magnus@hagander.net, david@lang.hm, scott.marlowe@gmail.com, 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: <48B7ACAA.7060800@hagander.net>
* 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