Horton

Re: better page-level checksums

Robert Haas <robertmhaas@gmail.com>

View thread
From: Robert Haas <robertmhaas@gmail.com>
To: Peter Geoghegan <pg@bowt.ie>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Bruce Momjian <bruce@momjian.us>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2022-06-14T20:22:42Z
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 3:25 PM Peter Geoghegan <pg@bowt.ie> wrote:
> I am proposing that we not commit ourselves to relying on implicit
> information about what must be true for every page in the cluster.
> Just having a little additional page-header metadata (in pd_flags)
> would accomplish that much, and wouldn't in itself impose any real
> overhead on TDE.
>
> It's not like the PageHeaderData.pd_flags bits are already a precious
> commodity, in the same way as the heap tuple infomask status bits are.
> We can afford to use some of them for this purpose, and then some.
>
> Why wouldn't we do it that way, just on general principle?
>
> You may still find it useful to rely on high level context at the
> level of code that runs on the server, perhaps for performance reasons
> (though it's unclear how much it matters). In which case the status
> bit is technically redundant information as far as the code is
> concerned. That may well be fine.

I still am not clear on precisely what you are proposing here. I do
agree that there is significant bit space available in pd_flags and
that consuming some of it wouldn't be stupid, but that doesn't add up
to a proposal. Maybe the proposal is: figure out how many different
configurations there are for this new kind of page space, let's say N,
and then reserve ceil(log2(N)) bits from pd_flags to indicate which
one we've got.

One possible problem with this is that, if the page is actually
encrypted, we might want pd_flags to also be encrypted. The existing
contents of pd_flags disclose some information about the tuples that
are on the page, so having them exposed to prying eyes does not seem
appealing.

-- 
Robert Haas
EDB: http://www.enterprisedb.com