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.
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 |