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 <br...@momjian.us> https://momjian.us EDB https://enterprisedb.com If only the physical world exists, free will is an illusion.
