On Mon, Apr 6, 2026 at 10:26 AM Alexey Makhmutov <[email protected]> wrote: > > > Originally in e981653 was used MarkBufferDirty() but 96ef3b8 flipped to > > MarkBufferDirtyHint(). > > Neither of these commits provided a comment on why this version was chosen. > > I think if we fix it we must comment things. > > I think that reason of change in 96ef3b8 (changing of 'MarkBufferDirty' > to 'MarkBufferDirtyHint') may be described in the next commit (9df56f6), > during the README update: > > New WAL records cannot be written during recovery, so hint bits set > during recovery must not dirty the page if the buffer is not already > dirty, when checksums are enabled. Systems in Hot-Standby mode may > benefit from hint bits being set, but with checksums enabled, a page > cannot be dirtied after setting a hint bit (due to the torn page risk). > So, it must wait for full-page images containing the hint bit updates to > arrive from the master. > > So, it seems logical, that any changes to the data not protected by the > WAL (which includes VM and FSM as well) should use MarkBufferDirtyHint, > which does not set dirty flag during recovery. However, as FSM blocks > could be just zeroed in case of checksums mismatch, so I think it's > perfectly fine to use regular MarkBufferDirty here.
Yea, I agree that this seems like simply an oversight in 96ef3b8. And it seems safe to use MarkBufferDirty() here instead. - Melanie
