From: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Brian Hurt <bhurt(at)janestcapital(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Block-level CRC checks |
Date: | 2008-10-02 14:08:23 |
Message-ID: | 48E4D5D7.7060300@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> writes:
>> Brian Hurt wrote:
>>> Another possibility is to just not checksum the hint bits...
>
>> That would work. But I'm afraid it'd make the implementation a lot more
>> invasive, and also slower. The buffer manager would have to know what
>> kind of a page it's dealing with, heap or index or FSM or what, to know
>> where the hint bits are. Then it would have to follow the line pointers
>> to locate the hint bits, and mask them out for the CRC calculation.
>
> Right. The odds are that this'd actually be slower than the
> double-buffer method, because of all the added complexity.
I was thinking that masking out the hint bits would be implemented by
copying the page to the temporary buffer, ANDing out the hint bits
there, and then calculating the CRC and issuing the write. So we'd still
need to double-buffer.
> The problem we still have to solve is torn pages when writing back a
> hint-bit update ...
Not checksumming the hint bits *is* a solution to the torn page problem.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Chernow | 2008-10-02 14:09:38 | Re: Block-level CRC checks |
Previous Message | Tom Lane | 2008-10-02 13:57:56 | Re: Block-level CRC checks |