Re: Protecting against unexpected zero-pages: proposal

From: Aidan Van Dyk <aidan(at)highrise(dot)ca>
To: Greg Stark <gsstark(at)mit(dot)edu>
Cc: Gurjeet Singh <singh(dot)gurjeet(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PGSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Protecting against unexpected zero-pages: proposal
Date: 2010-11-08 15:10:18
Message-ID: AANLkTi=JtCYr1eKXaCCV-h6H9noXWtfjsLs61uqXpH8q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Nov 7, 2010 at 1:04 AM, Greg Stark <gsstark(at)mit(dot)edu> wrote:
> It does seem like this is kind of part and parcel of adding checksums
> to blocks. It's arguably kind of silly to add checksums to blocks but
> have an commonly produced bitpattern in corruption cases go
> undetected.

Getting back to the checksum debate (and this seems like a
semi-version of the checksum debate), now that we have forks, could we
easily add block checksumming to a fork? IT would mean writing to 2
files but that shouldn't be a problem, because until the checkpoint is
done (and thus both writes), the full-page-write in WAL is going to
take precedence on recovery.

a.

--
Aidan Van Dyk                                             Create like a god,
aidan(at)highrise(dot)ca                                       command like a king,
http://www.highrise.ca/                                   work like a slave.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Stefan Kaltenbrunner 2010-11-08 15:27:39 Re: Should we use make -k on the buildfarm?
Previous Message Heikki Linnakangas 2010-11-08 13:40:10 Re: B-tree parent pointer and checkpoints