Re: better page-level checksums

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: better page-level checksums
Date: 2022-06-10 06:36:38
Message-ID: alpine.DEB.2.22.394.2206100831380.2183568@pseudo
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


Hello Robert,

> I think for this purpose we should limit ourselves to algorithms
> whose output size is, at minimum, 64 bits, and ideally, a multiple of
> 64 bits. I'm sure there are plenty of options other than the ones that
> btrfs uses; I mentioned them only as a way of jump-starting the
> discussion. Note that SHA-256 and BLAKE2B apparently emit enormously
> wide 16 BYTE checksums. That's a lot of space to consume with a
> checksum, but your chances of a collision are very small indeed.

My 0.02€ about that:

You do not have to store the whole hash algorithm output, you can truncate
or reduce (eg by xoring parts) the size to what makes sense for your
application and security requirements. ISTM that 64 bits is more than
enough for a page checksum, whatever the underlying hash algorithm.

Also, ISTM that a checksum algorithm does not really need to be
cryptographically strong, which means that cheaper alternatives are ok,
although good quality should be sought nevertheless.

--
Fabien.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bharath Rupireddy 2022-06-10 07:10:15 Re: Multi-Master Logical Replication
Previous Message Kyotaro Horiguchi 2022-06-10 06:33:36 Re: Using PQexecQuery in pipeline mode produces unexpected Close messages