On Sat, Nov 2, 2019 at 8:23 AM Antonin Houska <ah@cybertec.at> wrote:
> Change to hint bits does not result in LSN change in the case I described here
>
> https://www.postgresql.org/message-id/28452.1572443058%40antos
>
> but I consider this a bug (BTW, I discovered this problem when thinking about
> the use of LSN as encryption IV). Do you mean any other case? If LSN does not
> get changed, then the related full-page image WAL record is not guaranteed to
> be on disk during crash recovery. Thus if page checksum is invalid due to
> torn-page write, there's now WAL record to fix the page.
I thought the idea was that the first change to hint bits after a
given checkpoint produced an FPI, but subsequent changes within the
same checkpoint cycle do not. That's OK from a crash recovery
perspective, because redo begins at a checkpoint: either the page was
never modified after the last checkpoint, in which case the last write
to that relation was successfully fsync'd and the page is not torn, or
we restore an FPI at least once, which clobbers any torn page left
behind by the crash with a known good state. So a crash can lose some
hint bits settings, if they weren't the first to that page in that
checkpoint cycle, but it never leaves the page in an invalid state.
The same scheme will work for TDE as far as crash recovery is
concerned, but it seems like it has a cryptographic weakness if the
LSN is used as the IV, because the second hint bit write to the page
in the same checkpoint cycle would have no reason to bump the LSN,
which means you'd be encrypting with the same IV twice.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
