On Wed, Oct 6, 2021 at 9:35 AM Bruce Momjian <br...@momjian.us> wrote: > The above text isn't very clear. What I am saying is that currently > torn pages can be tolerated by hint bit writes because only a single > byte is changing. If we use a block cipher like AES-XTS, later 16-byte > encrypted blocks would be changed by hint bit changes, meaning torn > pages could not be tolerated. This means we would have to use full page > writes for hint bit changes, perhaps making this feature have > unacceptable performance overhead.
Actually, I think this would have *less* performance overhead than your patch. If you enable checksums or set wal_log_hints=on, then you might incur a some write-ahead log records that would otherwise be avoided, and those records will include full page images. This can happen once per page per checkpoint cycle. However, if the first modification to a particular page within a given checkpoint cycle is a regular WAL-logged operation rather than a hint bit change, then the extra WAL record and full-page image are not needed so the overhead is zero. Also, if the first modification is a hint bit change, and then the page is evicted, prompting a full page write, but a regular WAL-logged operation occurs later within the same checkpoint, the later operation no longer needs a full page write. So you still paid the cost of an extra WAL record, but you didn't pay the cost of an extra full page write. In other words, enabling checksums or turning wal_log_hints=on has a relatively low cost except when you have pages that incur only hint-type changes, and no regular changes, within the course of a single checkpoint cycle. On the other hand, in order to avoid IV reuse, your patch needed to bump the page LSN for every change, or at least for every eviction. That means you could potentially incur the overhead of an extra full page write multiple times per checkpoint cycle, and even if there were non-hint changes to that page in the same checkpoint cycle. Now you could say, well, let's not bump the page LSN for every hint-type change, and then your patch would have lower overhead than an approach based on XTS, but I think that also loses a ton of security, because now you're reusing IVs with an encryption system that is documented not to tolerate the reuse of IVs. I'm not here to try to pretend that encryption is going to be cheap. I just don't believe this particular argument about why AES-XTS should be more expensive. -- Robert Haas EDB: http://www.enterprisedb.com
