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

From Alvaro Herrera
Subject Re: Block-level CRC checks
Date
Msg-id 20081017152611.GH4218@alvh.no-ip.org
Whole thread Raw
In response to Block-level CRC checks  (Alvaro Herrera <alvherre@commandprompt.com>)
Responses Re: Block-level CRC checks
Re: Block-level CRC checks
Re: Block-level CRC checks
Re: Block-level CRC checks
Re: Block-level CRC checks
List pgsql-hackers
So this discussion died with no solution arising to the
hint-bit-setting-invalidates-the-CRC problem.

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.

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).

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.


pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: 8.3 .4 + Vista + MingW + initdb = ACCESS_DENIED
Next
From: "Jonah H. Harris"
Date:
Subject: Re: Block-level CRC checks