On Tue, May 25, 2021 at 09:42:48PM -0400, Stephen Frost wrote:
> The nonce needs to be a new one, if we include the hint bits in the set
> of data which is encrypted.
>
> However, what I believe folks are getting at here is that we could keep
> the LSN the same, but increase the nonce when the hint bits change, but
> *not* WAL log either the nonce change or the hint bit change (unless
> it's being logged for some other reason, in which case log both), thus
> reducing the amount of WAL being produced. What would matter is that
> both the hint bit change and the new nonce hit disk at the same time, or
> neither do, or we replay back to some state where the nonce and the hint
> bits 'match up' so that the page decrypts (and the integrity check
> works).
How do we prevent torn pages if we are writing the page with a new
nonce, and no WAL-logged full page image?
> That generally seems pretty reasonable to me and basically makes the
> increase in nonce work very much in the same manner that the hint bits
> themselves do- sometimes it changes even when the LSN doesn't but, in
> such cases, we don't actually WAL it, and that's ok because we don't
> actually care about it being updated- what's in the WAL when the page is
> replayed is perfectly fine and we'll just update the hint bits again
> when and if we decide we need to based on the actual visibility
> information at that time.
We get away with this because hint-bit only changes only change single
bytes on the page, and we can't tear a page between bytes, but if we
change the nonce, the entire page will have different bytes. What am I
missing here?
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com
If only the physical world exists, free will is an illusion.