| From: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
|---|---|
| To: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Block-level CRC checks |
| Date: | 2008-10-17 15:26:11 |
| Message-ID: | 20081017152611.GH4218@alvh.no-ip.org |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jonah H. Harris | 2008-10-17 15:42:39 | Re: Block-level CRC checks |
| Previous Message | Andrew Dunstan | 2008-10-17 15:00:02 | Re: 8.3 .4 + Vista + MingW + initdb = ACCESS_DENIED |