Re: better page-level checksums
Bruce Momjian <bruce@momjian.us>
From: Bruce Momjian <bruce@momjian.us>
To: Peter Geoghegan <pg@bowt.ie>
Cc: Robert Haas <robertmhaas@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2022-06-13T21:54:33Z
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 Mon, Jun 13, 2022 at 02:44:41PM -0700, Peter Geoghegan wrote: > On Fri, Jun 10, 2022 at 6:16 AM Robert Haas <robertmhaas@gmail.com> wrote: > > > My preference is for an approach that builds on that, or at least > > > doesn't significantly complicate it. So a cryptographic hash or nonce > > > can go in the special area proper (structs like BTPageOpaqueData don't > > > need any changes), but at a page offset before the special area proper > > > -- not after. > > > > > > What disadvantages does that approach have, if any, from your point of view? > > > > I think it would be an extremely good idea to store the extended > > checksum at the same offset in every page. Right now, code that wants > > to compute checksums, or a tool like pg_checksums that wants to verify > > them, can find the checksum without needing to interpret any of the > > remaining page contents. Things get sticky if you have to interpret > > the page contents to locate the checksum that's going to tell you > > whether the page contents are messed up. Perhaps this could be worked > > around if you tried hard enough, but I don't see what we get out of > > it. > > Is that the how block-level encryption feature from EDB Advanced Server does it? Uh, EDB Advanced Server doesn't have a block-level encryption feature. -- Bruce Momjian <bruce@momjian.us> https://momjian.us EDB https://enterprisedb.com Indecision is a decision. Inaction is an action. Mark Batterson