On Sat, Nov 2, 2019 at 8:23 AM Antonin Houska <a...@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