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+vFmv2Q3so4BHZj5O_=Dk9Y_x+JjZBbvk3CSFH22=p+g@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  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
On Sat, Jan 7, 2012 at 11:09 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
> On Sat, Jan 7, 2012 at 10:55 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
>
>> So there isn't any problem with there being incorrect checksums on
>> blocks and you can turn the parameter on and off as often and as
>> easily as you want. I think it can be USERSET but I wouldn't want to
>> encourage users to see turning it off as a performance tuning feature.
>> If the admin turns it on for the server, its on, so its SIGHUP.
>>
>> Any holes in that I haven't noticed?
>
> And of course, as soon as I wrote that I thought of the problem. We
> mustn't make a write that hasn't been covered by a FPW, so we must
> know ahead of time whether to WAL log hints or not. We can't simply
> turn it on/off any longer, now that we have to WAL log hint bits also.
> So thanks for making me think of that.
>
> We *could* make it turn on/off at each checkpoint, but its easier just
> to say that it can be turned on/off at server start.

Attached patch v6 now handles hint bits and checksums correctly,
following Heikki's comments.

In recovery, setting a hint doesn't dirty a block if it wasn't already
dirty. So we can write some hints, and we can set others but not write
them.

Lots of comments in the code.

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

Attachment

pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: Progress on fast path sorting, btree index creation time
Next
From: Simon Riggs
Date:
Subject: CLOG contention, part 2