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

From Simon Riggs
Subject Re: 16-bit page checksums for 9.2
Date
Msg-id CA+U5nM+iMQkJCxEdRNr7R0Sv9SnT21XjYbv-oxSEd9bngxRkpw@mail.gmail.com
Whole thread Raw
In response to Re: 16-bit page checksums for 9.2  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: 16-bit page checksums for 9.2
Re: 16-bit page checksums for 9.2
List pgsql-hackers
On Thu, Jan 5, 2012 at 3:46 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
> On Wed, Jan 4, 2012 at 1:35 PM, Kevin Grittner
> <Kevin.Grittner@wicourts.gov> wrote:

>> Sure.  I just think you are there already except for what I got into.

> New version attached, with your suggested changes included. Hole check
> code is there as well, but ifdef'd out since it isn't a valid check in
> all cases.

Following private discussions, Kevin showed me the patch at v3 was
inadequate because it didn't cater for torn pages as a result of hint
bit writes.

The following patch (v4) introduces a new WAL record type that writes
backup blocks for the first hint on a block in any checkpoint that has
not previously been changed. IMHO this fixes the torn page problem
correctly, though at some additional loss of performance but not the
total catastrophe some people had imagined. Specifically we don't need
to log anywhere near 100% of hint bit settings, much more like 20-30%
(estimated not measured).

Dan Scales also observed some cases where private writes aren't
checksummed, e.g. index build. Those suggestions are still outstanding
from me, but the v4 is worthy of more serious review.

I'll now turn my attention more fully onto the DW patch.

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

Attachment

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Poorly thought out code in vacuum
Next
From: Peter Geoghegan
Date:
Subject: Re: Progress on fast path sorting, btree index creation time