Re: better page-level checksums
Peter Geoghegan <pg@bowt.ie>
From: Peter Geoghegan <pg@bowt.ie>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Bruce Momjian <bruce@momjian.us>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2022-06-14T18:23:01Z
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 →
-
Rethink method for assigning OIDs to the template0 and postgres DBs.
- 2cb1272445d2 15.0 landed
-
pg_upgrade: Preserve database OIDs.
- aa01051418f1 15.0 landed
-
pg_upgrade: Preserve relfilenodes and tablespace OIDs.
- 9a974cbcba00 15.0 landed
-
Fix for new Boolean node
- cf925936ecc0 15.0 cited
-
Improve error handling of HMAC computations
- 5513dc6a304d 15.0 cited
-
Add macro RelationIsPermanent() to report relation permanence
- 95d77149c535 14.0 landed
-
Enhance nbtree index tuple deletion.
- d168b666823b 14.0 cited
On Tue, Jun 14, 2022 at 11:14 AM Robert Haas <robertmhaas@gmail.com> wrote: > We can have anything we want here, but we can't have everything we > want at the same time. There are irreducible engineering trade-offs > here. If all pages in a given cluster are the same, backends can > compute the values of things that are currently compile-time constants > upon startup and continue to use them for the lifetime of the backend. > If pages can vary, some encrypted or checksummed and others not, then > you have to recompute those values for every page. That's bound to > have some cost. It is also more flexible. Maybe not -- it depends on the particulars of the code. For example, it might be okay for the B-Tree code to assume that B-Tree pages have a special area at a known fixed offset, determined at compile time. At the same time, it might very well not be okay for a backup tool to make any such assumption, because it doesn't have the same context. Even within TDE, it might be okay to assume that it's a feature that the user must commit to using for a whole cluster at initdb time. What isn't okay is committing to that assumption now and forever, by leaving the door open to a world in which that assumption no longer holds. Like when you do finally get around to making TDE something that can work at the relation level, for example. Even if there is only a small chance of that ever happening, why wouldn't we be prepared for it, just on general principle? -- Peter Geoghegan