Horton

Re: storing an explicit nonce

Stephen Frost <sfrost@snowman.net>

View thread
From: Stephen Frost <sfrost@snowman.net>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Bruce Momjian <bruce@momjian.us>, Andres Freund <andres@anarazel.de>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Antonin Houska <ah@cybertec.at>, Ants Aasma <ants@cybertec.at>, Sasasu <i@sasa.su>
Date: 2021-10-07T18:53:18Z
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.

Greetings,

* Robert Haas (robertmhaas@gmail.com) wrote:
> On Thu, Oct 7, 2021 at 1:09 PM Bruce Momjian <bruce@momjian.us> wrote:
> > Are you saying a base backup could read a page from the file system and
> > see a partial write, even though the write is written as 8k?  I had not
> > thought about that.
> 
> Yes; see my other response.

Yes, that is something that has been seen before.

> > I think this whole discussion is about whether we need full page images
> > for hint bit changes.  I think we do if we use the LSN for the nonce (in
> > the old patch), and probably need it for hint bit changes when using
> > block cipher modes (XTS) if we feel basebackup could read only part of a
> > 16-byte page change.
> 
> I think all the encryption modes that we're still considering have the
> (very desirable) property that changing a single bit of the
> unencrypted page perturbs the entire output. But that just means that
> encrypted clusters will have to run in the same mode as clusters with
> checksums, or clusters with wal_log_hints=on, features which the
> community has already accepted as having reasonable overhead. I have
> in the past expressed skepticism about whether that overhead is really
> small enough to be considered acceptable, but if I recall correctly,
> the test results posted to the list suggest that you need a working
> set just a little bit large than shared_buffers to make it really
> sting. And that's not a super-common thing to do. Anyway, if people
> aren't screaming about the overhead of that system now, they're not
> likely to complain about applying it to some new situation either.

Agreed.

Thanks,

Stephen