On Thu, Apr 7, 2022 at 4:34 AM Matthias van de Meent <boekewurm+postg...@gmail.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
