On Thu, May 27, 2021 at 11:12 PM Bruce Momjian <br...@momjian.us> wrote:
> > Well, the code now does write full page images for hint bit changes, so > it should work fine. > > Yes, indeed it works well and I'd tested it. But here I want to make clear my understanding of the argument, if there is any problem please help me correct it. 1. Why couldn't we just throw away the hint bit change? Just don't encrypt them? Maybe we can expose the *pd_flags*, we needn't re-encrypt when it changed and there's no security risk. But there have many other changes that will call the function *MarkBufferDirtyHint* and we also needn't WAL log them too. We couldn't expose all of them, so the way "throw them away, don't encrypt them" is not feasible. 2. Why can we accept the performance degradation caused by checksum in this way, but TDE can't? The checksum must be implemented in this way, but in TDE maybe we can try another way to avoid this harm. 3. Another benefit of using the special space is that it's also can be used for AES-GCM to support integrity. I'm just a beginner of PG and may not have considered some obvious problems. But please let me put forward my rough idea again -- Why can't we simply use LSN+blockNum+checksum as nonce? When the checksums are enabled, every time we call the *MarkBufferDirtyHint* will generate a new LSN. So we can simply use the LSN+blockNum+0000 as the nonce. When the checksums are disabled, we can use these unused checksum values as a counter to make sure we have different nonce even if we don't write the new WAL record. -- There is no royal road to learning. HighGo Software Co.