Re: better page-level checksums

Michael Paquier <michael@paquier.xyz>

From: Michael Paquier <michael@paquier.xyz>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Peter Geoghegan <pg@bowt.ie>, Tom Lane <tgl@sss.pgh.pa.us>, Bruce Momjian <bruce@momjian.us>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2022-06-15T02:34:51Z
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.

On Tue, Jun 14, 2022 at 10:21:16PM -0400, Robert Haas wrote:
> On Tue, Jun 14, 2022 at 9:56 PM Peter Geoghegan <pg@bowt.ie> wrote:
>> Technically we don't already do that today, with the 16-bit checksums
>> that are stored in PageHeaderData.pd_checksum. But we do something
>> equivalent: low-level tools can still infer that checksums must not be
>> enabled on the page (really the cluster) indirectly in the event of a
>> 0 checksum. A 0 value can reasonably be interpreted as a page from a
>> cluster without checksums (barring page corruption). This is basically
>> reasonable because our implementation of checksums is guaranteed to
>> not generate 0 as a valid checksum value.
> 
> I don't think that 'pg_checksums -d' zeroes the checksum values on the
> pages in the cluster.

Saving the suspense..  pg_checksums --disable only updates the control
file to keep the operation cheap.
--
Michael