Re: Two issues leading to discrepancies in FSM data on the standby server

On Mon, Apr 6, 2026 at 10:26 AM Alexey Makhmutov
<a(dot)makhmutov(at)postgrespro(dot)ru> 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