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-14T18:52:06Z
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 2:23 PM Peter Geoghegan <pg@bowt.ie> wrote:
> 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?

To the extent that we can leave ourselves room to do new things in the
future without incurring unreasonable costs in the present, I'm in
favor of that, as I believe anyone would be. But as you say, a lot
depends on the specifics. Theoretical flexibility that can only be
used in practice by really slow code doesn't help anybody.

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