Re: CRC was: Re: beta testing version

ncm(at)zembu(dot)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