Re: Enabling Checksums - Mailing list pgsql-hackers

From Ants Aasma
Subject Re: Enabling Checksums
Date
Msg-id CA+CSw_v3PUaq_TD5gt+v1=7KSSPOKSKzkLDigg+TkpRpvB8gYQ@mail.gmail.com
Whole thread Raw
In response to Re: Enabling Checksums  (Bruce Momjian <bruce@momjian.us>)
Responses Re: Enabling Checksums  (Jeff Davis <pgsql@j-davis.com>)
List pgsql-hackers
On Mon, Mar 25, 2013 at 3:51 PM, Bruce Momjian <bruce@momjian.us> wrote:
> Great analysis.  Is there any logic to using a lighter-weight checksum
> calculation for cases where the corruption is rare?  For example, we
> know that network transmission can easily be corrupted, while buffer
> corruption is rare, and if corruption happens once, it is likely to
> happen again.

It's a matter of use-cases. 16bit (or 32bit, or even 64bit) checksums
will never be enough to give good enough guarantees about correctness
of data. They are at best the canaries in the coal mine, alerting
about underlying issues in the database setup. For our use case one
single corruption only has a fraction of a percent of chance of
escaping. Multiple errors quickly bring the probability of ignoring
corruption into the range of winning two lotteries at once while being
struck by lightning. The main thing to look out for is that we don't
have any blind spots for conceivable systemic errors. If we decide to
go with the SIMD variant then I intend to figure out what the blind
spots are and show that they don't matter.

Regards,
Ants Aasma
--
Cybertec Schönig & Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt
Web: http://www.postgresql-support.de



pgsql-hackers by date:

Previous
From: Darren Duncan
Date:
Subject: Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: Should array_length() Return NULL)
Next
From: Greg Stark
Date:
Subject: Re: Limiting setting of hint bits by read-only queries; vacuum_delay