Skip site navigation (1) Skip section navigation (2)

Re: 16-bit page checksums for 9.2

From: Greg Stark <stark(at)mit(dot)edu>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: Aidan Van Dyk <aidan(at)highrise(dot)ca>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: 16-bit page checksums for 9.2
Date: 2011-12-24 20:06:52
Message-ID: CAM-w4HOV41T6tXXS6n4o-GMW61jkxgo-8DQ-Px62Yy90COGgoA@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Sat, Dec 24, 2011 at 4:06 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> Checksums merely detect a problem, whereas FPWs correct a problem if
> it happens, but only in crash situations.
>
> So this does nothing to remove the need for FPWs, though checksum
> detection could be used for double write buffers also.

This is missing the point. If you have a torn page on a page that is
only dirty due to hint bits then the checksum will show a spurious
checksum failure. It will "detect" a problem that isn't there.

The problem is that there is no WAL indicating the hint bit change.
And if the torn page includes the new checksum but not the new hint
bit or vice versa it will be a checksum mismatch.

The strategy discussed in the past was moving all the hint bits to a
common area and skipping them in the checksum. No amount of double
writing or buffering or locking will avoid this problem.

-- 
greg

In response to

Responses

pgsql-hackers by date

Next:From: Simon RiggsDate: 2011-12-25 10:08:09
Subject: Re: 16-bit page checksums for 9.2
Previous:From: Greg StarkDate: 2011-12-24 19:41:04
Subject: Re: Moving more work outside WALInsertLock

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group