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

From Sam Mason
Subject Re: Block-level CRC checks
Date
Msg-id 20081001190305.GQ7271@frubble.xen.chris-lamb.co.uk
Whole thread Raw
In response to Re: Block-level CRC checks  (Alvaro Herrera <alvherre@commandprompt.com>)
Responses Re: Block-level CRC checks
List pgsql-hackers
On Wed, Oct 01, 2008 at 11:57:31AM -0400, Alvaro Herrera wrote:
> Tom Lane escribió:
> > "Jonah H. Harris" <jonah.harris@gmail.com> writes:
> 
> > > I probably wouldn't compare checksumming *every* WAL record to a
> > > single block-level checksum.
> > 
> > No, not at all.  Block-level checksums would be an order of magnitude
> > more expensive: they're on bigger chunks of data and they'd be done more
> > often.
> 
> More often?  My intention is that they are checked when the buffer is
> read in, and calculated/stored when the buffer is written out.
> In-memory changers of the block do not check nor recalculate the sum.

I know you said detecting memory errors wasn't being attempted, but
bad memory accounts for a reasonable number of reports of database
corruption on -general so I was wondering if moving the checks around
could catch some of these.

How about updating the block's checksum immediately whenever a tuple is
modified within it?  Checksums would be checked whenever data is read in
and just before it's written out.  Checksum failure on write would cause
PG to abort noisily with complaints about bad memory?

If some simple checksum could be found (probably a parity check) that
would allow partial updates PG wouldn't need to scan too much data when
regenerating it.  It would also cause the checksum to stay bad if data
goes bad in memory between reading from disk and its eventual write out,
a block remaining in cache for a large amount of time makes this case
appear possible.

 Sam


pgsql-hackers by date:

Previous
From: Gregory Stark
Date:
Subject: Re: Block-level CRC checks
Next
From: Josh Berkus
Date:
Subject: September CommitFest Closed