Thread

Re: RFC: PostgreSQL Storage I/O Transformation Hooks

Zsolt Parragi <zsolt.parragi@percona.com> — 2025-12-29T06:47:27Z

> Content of some WAL records can be almost completely predicated (it
> contains no user data,
> just some Postgres internal data which can be easily reconstructed).
> I wonder if this fact can significantly simplify task of cracking cypher?

AES is designed to resist known plaintext attacks, this isn't an issue
as long as the code doesn't reuse the same IV twice. The example code
uses a random iv for each WAL record, so that's unlikely.

This is a quite nice solution to keep the encryption of WAL as
parallel as possible. The downside is that it increases the size of
WAL a bit, uses MemoryContextAllowInCriticalSection, and this approach
is definitely slower during recovery than full page decryption.

On the other hand, per page WAL encryption can cause performance
issues with some workloads that write huge amounts of WAL with many
parallel clients. Both have pros and cons.

One thing that seems tricky is wal key rotation. The example code
ignores this, which is fine for a demo, but real extensions should be
able to handle it. We can't simply write a wal record about changing
the wal key, because without holding the write lock things could get
written out of order. The only safe solution I see is to also add the
id of the wal key to the additional wal record data, increasing the
record size even more.