|From:||"Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>|
|Cc:||<heikki(dot)linnakangas(at)enterprisedb(dot)com>,<aidan(at)highrise(dot)ca>, <stark(at)mit(dot)edu>, <pgsql-hackers(at)postgresql(dot)org>|
|Subject:||Re: 16-bit page checksums for 9.2|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
> Simon Riggs wrote:
> Kevin Grittner wrote:
>> if there is no checksum in the page itself, you can put one in the
>> double-write metadata.
> However, I don't see that it provides protection across non-crash
> write problems. We know we have these since many systems have run
> without a crash for years and yet still experience corrupt data.
Agreed. I don't think anyone has tried to assert it solves the same
problems that checksums solve -- it is a high-performance way to
solve some of the problems that an in-page checksum *creates* without
> Double writes do not require page checksums but neither do they
> replace page checksums.
To nit-pick: double writes require a page checksum, but (as Heikki
pointed out) they don't require it to be stored in the page. If
there *is* one stored in the page, it probably makes sense to use it.
> So I think we need page checksums plus either FPWs or double
Adding checksums by themselves creates a risk of false positive
corrupted page indications following an OS or hardware crash.
Additional FPWs or a new double-write mechanism are two of miriad
possible solutions to that. If it is going to be addressed for 9.2,
I believe they're the two most reasonable, especially from the POV of
So, while they should be separate patches, the complement each other;
each makes the other perform better, and they should share some code.
|Next Message||Aidan Van Dyk||2011-12-30 14:44:09||Re: 16-bit page checksums for 9.2|
|Previous Message||Kevin Grittner||2011-12-30 14:18:43||Re: 16-bit page checksums for 9.2|