Horton

Re: better page-level checksums

Fabien COELHO <coelho@cri.ensmp.fr>

View thread
From: Fabien COELHO <coelho@cri.ensmp.fr>
To: Robert Haas <robertmhaas@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2022-06-10T06:36:38Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Rethink method for assigning OIDs to the template0 and postgres DBs.

  2. pg_upgrade: Preserve database OIDs.

  3. pg_upgrade: Preserve relfilenodes and tablespace OIDs.

  4. Fix for new Boolean node

  5. Improve error handling of HMAC computations

  6. Add macro RelationIsPermanent() to report relation permanence

  7. Enhance nbtree index tuple deletion.

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.