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-14T19:13:28Z
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:01 PM Peter Geoghegan <pg@bowt.ie> wrote:
> A tool like pg_filedump or a backup tool can easily afford this
> overhead. The only cost that TDE has to pay for this added flexibility
> is that it has to set one of the PD_* bits in a code path that is
> already bound to be very expensive. What's so bad about that?
>
> Honestly, I'm a bit surprised that you're pushing back on this
> particular point. A nonce for TDE is just something that code in
> places like bufpage.h ought to know about. It has to be negotiated at
> that level, because it will in fact affect a lot of callers to the
> bufpage.h functions.

Peter, unless I have missed something, this email is the very first
one where you or anyone else have said anything at all about a PD_*
bit. Even here, it's not very clear exactly what you are proposing.
Therefore I have neither said anything bad about it in the past, nor
can I now answer the question as to what is "so bad about it." If you
want to make a concrete proposal, I will be happy to tell you what I
think about it.

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