Re: Block-level CRC checks

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Martijn van Oosterhout <kleptog(at)svana(dot)org>, Gregory Stark <stark(at)enterprisedb(dot)com>, Greg Stark <greg(dot)stark(at)enterprisedb(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Block-level CRC checks
Date: 2008-11-12 19:50:07
Message-ID: 20081112195007.GI4535@alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


Hmm, I can get around the btree problem by not summing the "special
space". This loses a bit of reliability because some of the most
critical bits of the page would not be protected by the CRC, but the
bulk of the data would be. And this allows me to get away from page
type specific tricks (like btpo_cycleid which is used as a hint bit).

The reason I noticed this is that I started wondering about only summing
the part of the page that's actually used, i.e. the header, the line
pointers, and the area beyond pd_upper. I then noticed that if I only
include the area between pd_upper and pd_special then I don't need to
care about those bits.

So far, the only other idea I've had is to keep a list of page types
(gin, gist, btree, hash, heap; am I missing something else?) and each
module would provide a routine to do the summing. (Or perhaps better:
the routine they provide says how to sum the special area of the page.
That would allow having a single routine to check the bulk of the page,
and the type-specific routine sums the summable parts of the special
area.)

Thoughts?

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Martijn van Oosterhout 2008-11-12 20:16:09 Re: Block-level CRC checks
Previous Message Tom Lane 2008-11-12 18:46:37 Re: [GENERAL] Very slow queries w/ NOT IN preparation (seems like a bug, test case)