Horton

Re: storing an explicit nonce

Robert Haas <robertmhaas@gmail.com>

View thread
From: Robert Haas <robertmhaas@gmail.com>
To: Bruce Momjian <bruce@momjian.us>
Cc: 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:44:43Z
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 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.

> 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.

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