Re: Disk corruption detection

From: "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>
To: Florian Weimer <fw(at)deneb(dot)enyo(dot)de>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Disk corruption detection
Date: 2006-06-12 20:44:51
Message-ID: 20060612204451.GE34196@pervasive.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Mon, Jun 12, 2006 at 07:55:22PM +0200, Florian Weimer wrote:
> * Jim C. Nasby:
>
> >> Anyway, how would be the chances for PostgreSQL to detect such a
> >> corruption on a heap or index data file? It's typically hard to
> >> detect this at the application level, so I don't expect wonders. I'm
> >> just curious if using PostgreSQL would have helped to catch this
> >> sooner.
> >
> > I know that WAL pages are (or at least were) CRC'd, because there was
> > extensive discussion around 32 bit vs 64 bit CRCs.
>
> CRCs wouldn't help because the out-of-date copy has got a correct CRC.
> That's why it's so hard to detect this problem at the application
> level. Putting redundancy into rows doesn't help, for instance.
>
> > There is no such check for data pages, although PostgreSQL has other
> > ways to detect errors. But in a nutshell, if you care about your
> > data, buy hardware you can trust.
>
> All hardware can fail. 8-/

I'd argue that any raid controller that carries on without degrading the
array even though it's getting write errors isn't worth the fiberglass
the components are soldered to. Same thing if it's a HD that can't write
something and doesn't throw an error back up the chain.
--
Jim C. Nasby, Sr. Engineering Consultant jnasby(at)pervasive(dot)com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461

In response to

Browse pgsql-general by date

  From Date Subject
Next Message jdwatson1 2006-06-12 21:44:34 BLOB & Searching
Previous Message Jim C. Nasby 2006-06-12 20:38:06 Re: Ever increasing OIDs - gonna run out soon?