Re: Block-level CRC checks - Mailing list pgsql-hackers

From Jonah H. Harris
Subject Re: Block-level CRC checks
Date
Msg-id 36e682920810170842w1ff3e521ncdf691e65c378f4c@mail.gmail.com
Whole thread Raw
In response to Re: Block-level CRC checks  (Alvaro Herrera <alvherre@commandprompt.com>)
Responses Re: Block-level CRC checks
List pgsql-hackers
On Fri, Oct 17, 2008 at 11:26 AM, Alvaro Herrera
<alvherre@commandprompt.com> wrote:
> So this discussion died with no solution arising to the
> hint-bit-setting-invalidates-the-CRC problem.

I've been busy.

> Apparently the only solution in sight is to WAL-log hint bits.  Simon
> opines it would be horrible from a performance standpoint to WAL-log
> every hint bit set, and I think we all agree with that.  So we need to
> find an alternative mechanism to WAL log hint bits.

Agreed.

> I thought about causing a process that's about to write a page check a
> flag that says "this page has been dirtied by someone who didn't bother
> to generate WAL".  If the flag is set, then the writer process is forced
> to write a WAL record containing all hint bits in the page, and only
> then it is allowed to write the page (and thus calculate the new CRC).

Interesting idea... let me ponder it for a bit.

-- 
Jonah H. Harris, Senior DBA
myYearbook.com


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Block-level CRC checks
Next
From: Andrew Chernow
Date:
Subject: Re: 8.3 .4 + Vista + MingW + initdb = ACCESS_DENIED