Re: 16-bit page checksums for 9.2 - Mailing list pgsql-hackers

From Kevin Grittner
Subject Re: 16-bit page checksums for 9.2
Date
Msg-id 4EFD774B0200002500044242@gw.wicourts.gov
Whole thread Raw
In response to 16-bit page checksums for 9.2  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
> 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
breaking pg_upgrade.
> 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
> writes.
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
pg_upgrade.
So, while they should be separate patches, the complement each other;
each makes the other perform better, and they should share some code.
-Kevin


pgsql-hackers by date:

Previous
From: "Kevin Grittner"
Date:
Subject: Re: 16-bit page checksums for 9.2
Next
From: Aidan Van Dyk
Date:
Subject: Re: 16-bit page checksums for 9.2