From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
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 13:57:56 |
Message-ID: | 27681.1222955876@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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. And it would
really suck from a modularity standpoint to have bufmgr know about all
that.
The problem we still have to solve is torn pages when writing back a
hint-bit update ...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2008-10-02 14:08:23 | Re: Block-level CRC checks |
Previous Message | Tom Lane | 2008-10-02 13:50:22 | Re: Interval output bug in HAVE_INT64_TIMESTAMP |