Re: better page-level checksums

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Peter Geoghegan <pg(at)bowt(dot)ie>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Bruce Momjian <bruce(at)momjian(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: better page-level checksums
Date: 2022-06-14 18:14:44
Message-ID: CA+TgmoYcLgbNru1XXFV+YPitYmmdOkyiPE8szawLbxDWi5dBmA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Jun 14, 2022 at 1:43 PM Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
> There is no doubt that it's not worth breaking on-disk compatibility
> just for pg_filedump. The important principle here is that
> high-context page formats are bad, and should be avoided whenever
> possible.

I agree.

> Why isn't it possible to avoid it here? We have all the bits we need
> for it in the page header, and then some. Why should we assume that
> it'll never be useful to apply encryption selectively, perhaps at the
> relation level?

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.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2022-06-14 18:23:01 Re: better page-level checksums
Previous Message Peter Eisentraut 2022-06-14 18:10:44 Re: Collation version tracking for macOS