On Wed, Jul 10, 2019 at 08:07:49PM -0400, Bruce Momjian wrote: > On Thu, Jul 11, 2019 at 12:18:47AM +0200, Tomas Vondra wrote: > > On Wed, Jul 10, 2019 at 06:04:30PM -0400, Stephen Frost wrote: > > > Greetings, > > > > > > * Tomas Vondra (tomas.von...@2ndquadrant.com) wrote: > > > > On Wed, Jul 10, 2019 at 04:11:21PM -0400, Alvaro Herrera wrote: > > > > >On 2019-Jul-10, Bruce Momjian wrote: > > > > > > > > > >>Uh, what if a transaction modifies page 0 and page 1 of the same table > > > > >>--- don't those pages have the same LSN. > > > > > > > > > >No, because WAL being a physical change log, each page gets its own > > > > >WAL record with its own LSN. > > > > > > > > > > > > > What if you have wal_log_hints=off? AFAIK that won't change the page > > > > LSN. > > > > > > Alvaro suggested elsewhere that we require checksums for these, which > > > would also force wal_log_hints to be on, and therefore the LSN would > > > change. > > > > > > > Oh, I see - yes, that would solve the hint bits issue. Not sure we want > > to combine the features like this, though, as it increases the costs of > > TDE. But maybe it's the best solution. > > Uh, why can't we just force log_hint_bits for encrypted tables? Why > would we need to use checksums as well?
When we were considering CBC mode for heap/index pages, a change of a hint bit would change all later 16-byte encrypted blocks. Now that we are using CTR mode, a change of a hint bit will only change a bit on the stored page. Someone could compare the old and new pages and see that a bit was changed. This would make log_hint_bits less of a requirement with CTR mode, though leaking hit bit changes is probably not ideal. Perhaps log_hint_bits should be a recommendation and not a requirement. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +