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

On Tue, Apr 14, 2026 at 7:22 PM Melanie Plageman
<melanieplageman@gmail.com> wrote:
> On Mon, Apr 6, 2026 at 10:26 AM Alexey Makhmutov
> <a.makhmutov@postgrespro.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.

I also think that usage of MarkBufferDirty() here is safe.  If I
understood correctly.
1) When wal_log_hints = on, should be completely safe.  Even if we
have torn page after the crash, during recovery FPI from the primary
should come first.
2) When wal_log_hints = off, we can end up with torn pages not covered
by FPI.  Without checksums, FSM can tolerate torn pages.  With
checksums, that would result in zeroed pages.  FSM can tolerate that
as well.  And the last shouldn't happen too frequently.  So, we should
finally get way better FSM state than it is now.

Should we push it to all supported branches?

------
Regards,
Alexander Korotkov
Supabase