Re: Protecting against unexpected zero-pages: proposal - Mailing list pgsql-hackers

From Greg Stark
Subject Re: Protecting against unexpected zero-pages: proposal
Date
Msg-id AANLkTik5fTNgM9y3i5zXgCgHW1dRVbJY5dQVyPj8MKOL@mail.gmail.com
Whole thread Raw
In response to Re: Protecting against unexpected zero-pages: proposal  (Jim Nasby <jim@nasby.net>)
List pgsql-hackers
On Tue, Nov 9, 2010 at 4:26 PM, Jim Nasby <jim@nasby.net> wrote:
>> On Tue, Nov 9, 2010 at 3:25 PM, Greg Stark <gsstark@mit.edu> wrote:
>>> Oh, I'm mistaken. The problem was that buffering the writes was
>>> insufficient to deal with torn pages. Even if you buffer the writes if
>>> the machine crashes while only having written half the buffer out then
>>> the checksum won't match. If the only changes on the page were hint
>>> bit updates then there will be no full page write in the WAL log to
>>> repair the block.
>
> If there's a torn page then we've crashed, which means we go through crash recovery, which puts a valid page (with
validCRC) back in place from the WAL. What am I missing?
 

"If the only changes on the page were hint bit updates then there will
be no full page write in the WAL to repair the block"



-- 
greg


pgsql-hackers by date:

Previous
From: Gurjeet Singh
Date:
Subject: DROP TABLESPACE needs crash-resistance
Next
From: Aidan Van Dyk
Date:
Subject: Re: Protecting against unexpected zero-pages: proposal