Greetings,
* Bruce Momjian (bruce@momjian.us) wrote:
> On Tue, Jan 12, 2021 at 09:40:53PM +0900, Masahiko Sawada wrote:
> > > This says:
> > >
> > > https://wiki.postgresql.org/wiki/Transparent_Data_Encryption#Other_requirements
> > >
> > > wal_log_hints will be enabled automatically in encryption mode.
> > >
> > > Does that help?
> >
> > IIUC it helps but not enough. When wal_log_hints is enabled, we write
> > a full-page image when updating hint bits if it's the first time
> > change for the page since the last checkpoint. But I'm concerned that
> > what if we change hint bits again after the page is flushed. We would
> > mark the page as dirtied but not write any WAL, leaving the page lsn
> > as it is.
>
> I updated the wiki to be:
>
> https://wiki.postgresql.org/wiki/Transparent_Data_Encryption#Other_requirements
>
> wal_log_hints will be enabled automatically in encryption mode. However,
> more than one hit change between checkpoints does not cause WAL
> activity, which would cause the same LSN to be used for different pages
> images.
>
> I think one big question is that, since we are using a streaming cipher,
> do we care about hint bit changes showing to users? I actually don't
> know. If we do, some kind of dummy LSN record might be required, as you
> suggested.
I don't think there's any doubt that we need to make sure that the IV is
distinct and advancing the LSN to get a new one when needed for this
case seems like it's probably the way to do that. Hint bit change
visibility to users isn't really at issue here- we can't use the same IV
multiple times. The two options that we have are to either not actually
update the hint bit in such a case, or to make sure to change the
LSN/IV. Another option would be to, if we're able to make a hole to put
the GCM tag on to the page somewhere, further widen that hole to include
an additional space for a counter that would be mixed into the IV, to
avoid having to do an XLOG NOOP.
Thanks,
Stephen
