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

From Jonah H. Harris
Subject Re: Block-level CRC checks
Date
Msg-id 36e682920810012229q1d4becd8q7660bb0e443ca104@mail.gmail.com
Whole thread Raw
In response to Re: Block-level CRC checks  (Aidan Van Dyk <aidan@highrise.ca>)
Responses Re: Block-level CRC checks
Re: Block-level CRC checks
Re: Block-level CRC checks
List pgsql-hackers
Rather than potentially letting this slide past 8.4, I threw together
an extremely quick-hack patch at the smgr-layer for block-level
checksums.

There are some nasties in that the CRC is the first member of
PageHeaderData (in order to guarantee inclusion of the LSN), and that
it bumps the size of the page header from 24-32 bytes on MAXALIGN=8.
I really think most people should use checksums and so I didn't make
it optional storage within the page (which would of course increase
the complexity).

Second, I didn't bump page version numbers.

Third, rather than a zero-filled page (which has been commonplace for
as long as I can remember), I used a fixed magic number (0xdeadbeef)
for pd_checksum as the default CRC; that way, if someone
enables/disables it at runtime, they won't get invalid checksums for
blocks which hadn't been checksummed previously.  This may as well be
zero (which means PageInit/PageHeaderIsValid wouldn't have to be
touched), but I used it as a test.

I ran the regressions and several concurrent benchmark tests which
passed successfully, but I'm sure I'm missing quite a bit due to the
the fact that it's late, it's just a quick hack, and I haven't gone
through the buffer manager locking code in awhile.

I'll be happy to work on this or let Alvaro take it; just as long as
it gets done for 8.4.

--
Jonah H. Harris, Senior DBA
myYearbook.com

Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Common Table Expressions (WITH RECURSIVE) patch
Next
From: "Jonah H. Harris"
Date:
Subject: Re: Block-level CRC checks