On Wed, Oct 01, 2008 at 11:57:31AM -0400, Alvaro Herrera wrote: > Tom Lane escribió: > > "Jonah H. Harris" <[EMAIL PROTECTED]> 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
