On 10.06.22 15:16, Robert Haas wrote:
> I'm not perfectly attached to the idea of using SHA here, but it seems
> to me that's pretty much the standard thing these days. Stephen Frost
> and David Steele pushed hard for SHA checksums in backup manifests,
> and actually wanted it to be the default.
That seems like a reasonable use in that application, since you might
want to verify whether a backup has been (maliciously?) altered rather
than just accidentally bit flipped.
> I think that if you're the kind of person who looks at our existing
> page checksums and finds them too weak, I doubt that CRC-32C is going
> to make you feel any better. You're probably the sort of person who
> thinks that checksums should have a lot of bits, and you're probably
> not going to be satisfied with the properties of an algorithm invented
> in the 1960s. Of course if there's anyone out there who thinks that
> our existing 16-bit checksums are a pile of garbage but would be much
> happier if CRC-32C is an option, I am happy to have them show up here
> and say so, but I find it much more likely that people who want this
> kind of feature would advocate for a more modern algorithm.
I think there ought to be a bit more principled analysis here than just
"let's add a lot more bits". There is probably some kind of information
to be had about how many CRC bits are useful for a given block size, say.
And then there is the question of performance. When data checksum were
first added, there was a lot of concern about that. CRC is usually
baked directly into hardware, so it's about as cheap as we can hope for.
SHA not so much.