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+U5nMKu2Oy097fyV8qFTWVO7fyx5D_-5q=Nhd_64Yr0Bzq0+g@mail.gmail.com
Whole thread Raw
In response to Re: 16-bit page checksums for 9.2  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
List pgsql-hackers
On Wed, Dec 28, 2011 at 5:45 PM, Heikki Linnakangas
<heikki.linnakangas@enterprisedb.com> wrote:
> On 28.12.2011 11:22, Simon Riggs wrote:
>>
>> On Wed, Dec 28, 2011 at 7:42 AM, Heikki Linnakangas
>> <heikki.linnakangas@enterprisedb.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


pgsql-hackers by date:

Previous
From: Boszormenyi Zoltan
Date:
Subject: Re: ECPG FETCH readahead
Next
From: Pavel Stehule
Date:
Subject: failed regress test