pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  

help / color / mirror / Atom feed
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:52:00 -0600
Message-ID: <dcc563d10808281852l21d81fdcm74db42126f0968a7@mail.gmail.com> (raw)
In-Reply-To: <alpine.DEB.1.10.0808281814100.2713@asgard.lang.hm>
References: <BAY124-W57D3654AF1159CAF8EAC19F5660@phx.gbl>
	<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>

On Thu, Aug 28, 2008 at 7:16 PM,  <david@lang.hm> wrote:
> 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.

And if any of those things happens, the machine will shut down and
you'll be safe.

> if killing the process voids all the ACID protection then something is
> seriously wrong.

No, your understanding of what postgresql can expect to have happen to
it are wrong.

You'll lose data integrity if:
If a CPU starts creating bad output that gets written to disk,
your RAID controller starts writing garbage to disk,
your memory has bad bits and you don't have ECC,
Some program hijacks a postgres process and starts writing random bits
in the code,
some program comes along and kills the postmaster, which coordinates
all the backends, and corrupts shared data in the process.

> it may loose transactions that are in flight, but it should not corrupt the
> database.

That's true for anything that just stops the machine or all the
postgresql processes dead.

It's not true for a machine that is misbehaving.  And any server that
randomly kills processes is misbehaving.



view thread (65+ messages)  latest in thread

Message-ID: <dcc563d10808281852l21d81fdcm74db42126f0968a7@mail.gmail.com>
Permalink:  ../dcc563d10808281852l21d81fdcm74db42126f0968a7@mail.gmail.com/
Also on:    postgresql.org/message-id/dcc563d10808281852l21d81fdcm74db42126f0968a7@mail.gmail.com

 · 

reply
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: <dcc563d10808281852l21d81fdcm74db42126f0968a7@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