Re: Enabling Checksums - Mailing list pgsql-hackers

From Craig Ringer
Subject Re: Enabling Checksums
Date
Msg-id 514D1E1B.7020600@2ndquadrant.com
Whole thread Raw
In response to Re: Enabling Checksums  (Jeff Davis <pgsql@j-davis.com>)
Responses Re: Enabling Checksums  (Ants Aasma <ants@cybertec.at>)
List pgsql-hackers
On 03/23/2013 02:00 AM, Jeff Davis wrote:
> On Fri, 2013-03-22 at 17:09 +0200, Ants Aasma wrote:
>> So to conclude, the 3 approaches:
> One other question: assuming that the algorithms use the full 16-bit
> space, is there a good way to avoid zero without skewing the result? Can
> we do something like un-finalize (after we figure out that it's zero),
> compute in an extra salt value, and then re-finalize? That might work
> for Fletcher; but I don't think that works for CRC or Fowler-Noll-Vo
> because the final value is the same as the state.
>
> I'm still slightly concerned about differentiating checksummed pages in
> the future if we want to offer a transition path, since we no longer use
> header bits. Avoiding zero might help us there. Hopefully not necessary,
> but something we might find useful.
Avoiding a magic value for "not checksummed" might help, but IMO zero is
a terrible choice for that since it's one of the most likely things to
be written in chunks over good data during some kinds of corruption
event (memory overwriting, etc).

Making zero a "not checksummed" magic value would significantly detract
from the utility of checksums IMO.
>  Also, it would help us identify
> situations where the checksum is never set.
Now that seems more useful - "ERROR: BUG or disk corruption found".

-- Craig Ringer                   http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services




pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Support for REINDEX CONCURRENTLY
Next
From: Atri Sharma
Date:
Subject: Re: Page replacement algorithm in buffer cache