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

Re: 16-bit page checksums for 9.2

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, stark(at)mit(dot)edu, aidan(at)highrise(dot)ca, pgsql-hackers(at)postgresql(dot)org
Subject: Re: 16-bit page checksums for 9.2
Date: 2011-12-29 10:58:38
Message-ID: CA+U5nMKu2Oy097fyV8qFTWVO7fyx5D_-5q=Nhd_64Yr0Bzq0+g@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Wed, Dec 28, 2011 at 5:45 PM, Heikki Linnakangas
<heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
> On 28.12.2011 11:22, Simon Riggs wrote:
>>
>> On Wed, Dec 28, 2011 at 7:42 AM, Heikki Linnakangas
>> <heikki(dot)linnakangas(at)enterprisedb(dot)com>  wrote:
>>
>>>> How would you know when to look in the double write buffer?
>>>
>>>
>>>
>>> You scan the double-write buffer, and every page in the double write
>>> buffer
>>> that has a valid checksum, you copy to the main storage. There's no need
>>> to
>>> check validity of pages in the main storage.
>>
>>
>> OK, then we are talking at cross purposes. Double write buffers, in
>> the way you explain them allow us to remove full page writes. They
>> clearly don't do anything to check page validity on read. Torn pages
>> are not the only fault we wish to correct against... and the double
>> writes idea is orthogonal to the idea of checksums.
>
>
> The reason we're talking about double write buffers in this thread is that
> double write buffers can be used to solve the problem with hint bits and
> checksums.

Torn pages are not the only problem we need to detect.

You said "You scan the double write buffer...". When exactly would you do that?

Please explain how a double write buffer detects problems that do not
occur as the result of a crash.

We don't have much time, so please be clear and lucid.

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

In response to

pgsql-hackers by date

Next:From: Pavel StehuleDate: 2011-12-29 12:27:35
Subject: failed regress test
Previous:From: Boszormenyi ZoltanDate: 2011-12-29 09:46:23
Subject: Re: ECPG FETCH readahead

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