Skip site navigation (1) Skip section navigation (2)

Re: Block-level CRC checks

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: Gregory Stark <stark(at)enterprisedb(dot)com>
Cc: Martijn van Oosterhout <kleptog(at)svana(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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-13 18:00:00
Message-ID: 20081113180000.GC4062@alvh.no-ip.org (view raw or flat)
Thread:
Lists: pgsql-hackers
Gregory Stark wrote:

> I think we're talking past each other. Martin and I are talking about doing
> something like:
> 
> for (...)
>   ...
>   crc(word including hint bits)
>   ...
> for (each line pointer)
>   crc-negated(word & LP_DEAD<<15)
>  
> Because CRC is a cyclic checksum it's possible to add or remove bits
> incrementally.

I see.

Since our CRC implementation is a simple byte loop, and since ItemIdData
fits in a uint32, the attached patch should do mostly the same by
copying the line pointer into a uint32, turning off the lp_flags, and
summing the modified copy.

This patch is also skipping pd_special and the unused area of the page.

I'm still testing this; please beware that this likely has an even
higher bug density than my regular patches (and some debugging printouts
as well).

While reading the pg_filedump code I noticed that there's a way to tell
the different index pages apart, so perhaps we can use that to be able
to checksum the special space as well.

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Attachment: blkcrc-11.patch
Description: text/x-diff (27.0 KB)

In response to

Responses

pgsql-hackers by date

Next:From: Josh BerkusDate: 2008-11-13 18:07:24
Subject: Re: Simple postgresql.conf wizard
Previous:From: Decibel!Date: 2008-11-13 17:58:45
Subject: Re: WIP: Automatic view update rules

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group