Re: storing an explicit nonce
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Stephen Frost <sfrost@snowman.net>
Cc: Ants Aasma <ants@cybertec.at>, Bruce Momjian <bruce@momjian.us>,
Sasasu <i@sasa.su>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2021-10-05T17:26:04Z
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 →
-
Rethink method for assigning OIDs to the template0 and postgres DBs.
- 2cb1272445d2 15.0 landed
-
pg_upgrade: Preserve database OIDs.
- aa01051418f1 15.0 landed
-
pg_upgrade: Preserve relfilenodes and tablespace OIDs.
- 9a974cbcba00 15.0 landed
-
Fix for new Boolean node
- cf925936ecc0 15.0 cited
-
Improve error handling of HMAC computations
- 5513dc6a304d 15.0 cited
-
Add macro RelationIsPermanent() to report relation permanence
- 95d77149c535 14.0 landed
-
Enhance nbtree index tuple deletion.
- d168b666823b 14.0 cited
On Tue, Oct 5, 2021 at 1:24 PM Robert Haas <robertmhaas@gmail.com> wrote: > On Mon, Oct 4, 2021 at 10:00 PM Stephen Frost <sfrost@snowman.net> wrote: > > I do want to point out, as I think I did when we discussed this but want > > to be sure it's also captured here- I don't think that temporary file > > access should be forced to be block-oriented when it's naturally (in > > very many cases) sequential. To that point, I'm thinking that we need a > > temp file access API through which various systems work that's > > sequential and therefore relatively similar to the existing glibc, et > > al, APIs, but by going through our own internal API (which more > > consistently works with the glibc APIs and provides better error > > reporting in the event of issues, etc) we can then extend it to work as > > an encrypted stream instead. > > Regarding this, would it use block-oriented access on the backend? > > I agree that we need a better API layer through which all filesystem > access is routed. One of the notable weaknesses of the Cybertec patch > is that it has too large a code footprint, (sent too soon) ...precisely because PostgreSQL doesn't have such a layer. But I think ultimately we do want to encrypt and decrypt in blocks, so if we create such a layer, it should expose byte-oriented APIs but combine the actual I/Os somehow. That's also good for cutting down the number of system calls, which is a benefit unto itself. -- Robert Haas EDB: http://www.enterprisedb.com