> 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

Next:	From: Aidan Van Dyk	Date: 2011-12-30 14:44:09
	Subject: Re: 16-bit page checksums for 9.2
Previous:	From: Kevin Grittner	Date: 2011-12-30 14:18:43
	Subject: Re: 16-bit page checksums for 9.2