Re: Disk corruption detection - Mailing list pgsql-general

From Florian Weimer
Subject Re: Disk corruption detection
Date
Msg-id 87irn6b6np.fsf@mid.deneb.enyo.de
Whole thread Raw
In response to Re: Disk corruption detection  ("Jim C. Nasby" <jnasby@pervasive.com>)
Responses Re: Disk corruption detection
List pgsql-general
* 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-/

AFAIK, compare-on-read is the recommend measure to compensate for this
kind of failure.  (The traditional recommendation also includes three
disks, so that you've got a tie-breaker.)  It seems to me that
PostgreSQL's MVCC-related "don't directly overwrite data rows" policy
might help to expose this sooner than with direct B-tree updates.

In this particular case, we would have avoided the failure if we
properly monitored the disk subsystem (the failure was gradual).
Fortunately, it was just a test system, but it got me woried a bit.

pgsql-general by date:

Previous
From: Florian Weimer
Date:
Subject: Re: Disk corruption detection
Next
From: Florian Weimer
Date:
Subject: Re: Fabian Pascal and RDBMS deficiencies in fully