Re: better page-level checksums - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: better page-level checksums
Date
Msg-id CAH2-WzncBSSsbqM+=kvPv7sxVZzN8i-RD_SyX8bQDeeNcP0rrA@mail.gmail.com
Whole thread Raw
In response to Re: better page-level checksums  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: better page-level checksums  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Tue, Jun 14, 2022 at 7:17 PM Robert Haas <robertmhaas@gmail.com> wrote:
> But it seems
> absolutely clear that our goal ought to be to leak as little
> information as possible.

But at what cost?

Basically I think that this is giving up rather a lot. For example,
isn't it possible that we'd have corruption that could be a bug in
either the checksum code, or in recovery?

I'd feel a lot better about it if there was some sense of both the
costs and the benefits.

> > Let's assume for now that we don't leave pd_flags unencrypted, as you
> > have suggested. We're still discussing new approaches to checksumming
> > in the scope of this work, which of course includes many individual
> > cases that don't involve any encryption. Plus even with encryption
> > there are things like defensive assertions that can be added by using
> > a flag bit for this.
>
> True. I don't think we should be too profligate with those bits just
> in case somebody needs a bunch of them for something important in the
> future, but it's probably fine to use up one or two.

Sure, but how many could possibly be needed for this? I can't see it
being more than 2 or 3. Which seems absolutely fine. They *definitely*
have no value if nobody ever uses them for anything.

-- 
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: better page-level checksums
Next
From: Michael Paquier
Date:
Subject: Re: better page-level checksums