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

Re: Block-level CRC checks

From: Andrew Chernow <ac(at)esilo(dot)com>
To: "Jonah H(dot) Harris" <jonah(dot)harris(at)gmail(dot)com>
Cc: Aidan Van Dyk <aidan(at)highrise(dot)ca>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Gregory Stark <stark(at)enterprisedb(dot)com>, pgsql(at)mohawksoft(dot)com, Hannu Krosing <hannu(at)2ndquadrant(dot)com>, "Decibel!" <decibel(at)decibel(dot)org>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Block-level CRC checks
Date: 2008-10-02 14:09:38
Message-ID: 48E4D622.1010608@esilo.com (view raw or flat)
Thread:
Lists: pgsql-hackers
Jonah H. Harris wrote:
> On Thu, Oct 2, 2008 at 1:29 AM, Jonah H. Harris <jonah(dot)harris(at)gmail(dot)com> wrote:
>> 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.
> 
> Don't know how I missed this obvious one... should not be coding this
> late @ night :(
> 
> Patch updated.
> 

I read through this patch and am curious why 0xdeadbeef was used as an 
uninitialized value for the page crc.  Is this value somehow less likely 
to have collisons than zero (or any other arbitrary value)?

Would it not be better to add a boolean bit or byte to inidcate the crc 
state?

-- 
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/

In response to

Responses

pgsql-hackers by date

Next:From: Alvaro HerreraDate: 2008-10-02 14:15:10
Subject: Re: Transactions within a function body
Previous:From: Heikki LinnakangasDate: 2008-10-02 14:08:23
Subject: Re: Block-level CRC checks

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