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 AANLkTimu5Ac21xu366f+8sXYwWXs_RPmJVd84XSqLFEx@mail.gmail.com
Whole thread Raw
In response to Re: Protecting against unexpected zero-pages: proposal  (Greg Stark <gsstark@mit.edu>)
Responses Re: Protecting against unexpected zero-pages: proposal
List pgsql-hackers
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.

Huh, this implies that if we did go through all the work of
segregating the hint bits and could arrange that they all appear on
the same 512-byte sector and if we buffered them so that we were
writing the same bits we checksummed then we actually *could* include
them in the CRC after all since even a torn page will almost certainly
not tear an individual sector.

-- 
greg


pgsql-hackers by date:

Previous
From: Greg Stark
Date:
Subject: Re: Protecting against unexpected zero-pages: proposal
Next
From: Viktor Valy
Date:
Subject: TODO Alter Table Rename Constraint