Re: Preventing indirection for IndexPageGetOpaque for known-size page special areas

On Thu, Apr 7, 2022 at 4:34 AM Matthias van de Meent
<boekewurm+postgres(at)gmail(dot)com> wrote:
> Also, I can't see why we would allow page-level layout changes in
> initdb; that seems like the wrong place to do that. All page layout
> currently is at compile-time; even checksums (which can be
> enabled/disabled in initdb) have reserved space available in the page
> header. Why would it be different for nonces?

Because there's no place to put them in the existing page format. We
jammed checksums into the 2-byte field that had previously been set
aside for the TLI, but that wasn't really an ideal solution because it
meant we ended up with a checksum that is only 16 bits wide. However,
the 2 bytes set aside for the TLI weren't really being used
effectively anyway, so repurposing them was relatively easy, and a
16-bit checksum is better than nothing.

For encryption or integrity verification, you need a lot more space,
like 16-32 bytes. I can't see us adding that unilaterally to every
cluster, because (1) it would break pg_upgrade compatibility, (2) it's
a pretty significant amount of space to set aside in every single
cluster whether it is using those features or not, and (3) the
technology is constantly evolving and we can't predict how many bytes
will be needed in the future. AES in whatever mode we use it requires
whatever number of bytes it does, but AES replaced DES and will in
turn be replaced by something else which can have totally different
requirements.

I do understand that there are significant challenges and performance
concerns around having these kinds of initdb-controlled page layout
changes, so the future of that patch is unclear. However, I don't
think that it's practical to say that a 16-bit checksum should be good
enough for everyone, and I also don't think it's practical to say that
if you want a wider checksum or to use encryption or whatever, you
have to recompile from source. Most users are going to get precompiled
binaries from a vendor, and those binaries need to be able to work in
all the configurations that users want to use. It's OK for
experimental things that we only expect developers to fool with to
require recompiling, but things that users have a legitimate need to
reconfigure need to be initdb-time controllable at worst. Hence
fc49e24fa69a15efacd5b8958115ed9c43c48f9a, for example.

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