From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: better page-level checksums |
Date: | 2022-06-13 22:26:05 |
Message-ID: | CAH2-WznPTrCiuMvzdsT+nPaZkAtn2c60jTpsH36XEd_FwYyaXQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Jun 13, 2022 at 3:06 PM Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> That is encryption done in a virtual file system independent of
> Postgres. So, I guess the answer to your question is that this is not
> how EDB Advanced Server does it.
Okay, thanks for clearing that up. The term "block based" does appear
in the article I linked to, so you can see why I didn't understand it
that way initially.
Anyway, I can see how it would be useful to be able to know the offset
of a nonce or of a hash digest on any given page, without access to a
running server. But why shouldn't that be possible with other designs,
including designs closer to what I've outlined?
A known fixed offset in the special area already assumes that all
pages must have a value in the first place, even though that won't be
true for the majority of individual Postgres servers. There is
implicit information involved in a design like the one Robert has
proposed; your backup tool (or whatever) already has to understand to
expect something other than no encryption at all, or no checksum at
all. Tools like pg_filedump already rely on implicit information about
the special area.
I'm not against the idea of picking a handful of checksum/encryption
schemes, with the understanding that we'll be committing to those
particular schemes indefinitely -- it's not reasonable to expect
infinite flexibility here (and so I don't). But why should we accept
something that seems to me to be totally inflexible, and doesn't
compose with other things?
--
Peter Geoghegan
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2022-06-13 23:15:29 | Re: Checking for missing heap/index files |
Previous Message | David Zhang | 2022-06-13 22:18:45 | Re: Non-replayable WAL records through overflows and >MaxAllocSize lengths |