Re: CRC was: Re: beta testing version

ncm@zembu.com (Nathan Myers) writes:
> 2. I disagree with way the above statistics were computed.  That eleven 
>    million-year figure gets whittled down pretty quickly when you 
>    factor in all the sources of corruption, even without crashes.  
>    (Power failures are only one of many sources of corruption.)  They 
>    grow with the size and activity of the database.  Databases are 
>    getting very large and busy indeed.

Sure, but the argument still holds.  If the net MTBF of your underlying
system is less than a day, it's too unreliable to run a database that
you want to trust.  Doesn't matter what the contributing failure
mechanisms are.  In practice, I'd demand an MTBF of a lot more than a
day before I'd accept a hardware system as satisfactory...

> 3. Many users clearly hope to be able to pull the plug on their hardware 
>    and get back up confidently.  While we can't promise they won't have 
>    to go to their backups, we should at least be equipped to promise,
>    with confidence, that they will know whether they need to.

And the difference in odds between 2^32 and 2^64 matters here?  I made
a numerical case that it doesn't, and you haven't refuted it.  By your
logic, we might as well say that we should be using a 128-bit CRC, or
256-bit, or heck, a few kilobytes.  It only takes a little longer to go
up each step, right, so where should you stop?  I say MTBF measured in
megayears ought to be plenty.  Show me the numerical argument that 64
bits is the right place on the curve.

> 4. For a way to mark the "current final" log entry, you want a lot more
>    confidence, because you read a lot more of them,

You only need to make the distinction during a restart, so I don't
think that argument is correct.
        regards, tom lane