Re: Block-level CRC checks - Mailing list pgsql-hackers

From Harald Armin Massa
Subject Re: Block-level CRC checks
Date
Msg-id 7be3f35d0810010256h5e4b8aaewb66d2ce4d4734f3f@mail.gmail.com
Whole thread Raw
In response to Re: Block-level CRC checks  (Zdenek Kotala <Zdenek.Kotala@Sun.COM>)
Responses Re: Block-level CRC checks
List pgsql-hackers
CRC-checks will help to detect corrupt data.

my question:

WHAT should happen when corrupted data is detected?

a) PostgreSQL can end with some paniccode
b) a log can be written, with some rather high level

a) has the benefit that it surely will be noticed. Which is  a real
benefet, as I suppose that many users of PostgreSQL on the low end do
not have dedicated DBA-Admins who read the *.log every day

b) has the benefit that work goes on


BUT:
What can somebody do AFTER PostgreSQL has detected "data is corrupted,
CRC error in block xxxx" ?

My first thought of action would be: get new drive, pg_dump_all to
save place, install new drive, pg_restore
BUT: how will pg_dump_all be enabled? As PostgreSQL must be forced to
accept the corrupted data to do a pg_dump...

Next step: for huge databases it is tempting to not pg_dump, but
filecopy; with shut down database or pg_backup() etc. What way can
that be supported while data is corrupted?

Please do not misunderstand my question  ... I really look forward to
get this kind of information; especially since corrupted data on hard
drives is an early sign of BIG trouble to come. I am just asking to
start thinking about "what do after corruption has been detected"


Harald

--
GHUM Harald Massa
persuadere et programmare
Harald Armin Massa
Spielberger Straße 49
70435 Stuttgart
0173/9409607
no fx, no carrier pigeon
-
EuroPython 2009 will take place in Birmingham - Stay tuned!


pgsql-hackers by date:

Previous
From: Zdenek Kotala
Date:
Subject: Re: Block-level CRC checks
Next
From: Gregory Stark
Date:
Subject: Re: Initial prefetch performance testing