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

Hi Alexander,

On Sun, Sep 7, 2026 at 3:22 PM Alexander Korotkov wrote:
> 0001 is revert
> 0002 is patch for FSM readme to highlight this aspect
>
> I'm going to push (and backpatch) 0001. 0002 needs review.

The revert looks correct to me. The heap WAL record drives the FSM
update during redo, but it contains neither a block reference nor an FPI
for the FSM page. MarkBufferDirty() therefore lets the page reach disk
without torn-page protection.

I agree with the README change. "Repairable by a later FPI" could
sound like an unrelated future FPI is expected to repair the page.
Perhaps the paragraph could instead say that, when hint changes require
WAL protection and full_page_writes is enabled, MarkBufferDirtyHint()
either provides that protection before a newly dirtied page can reach
disk or, during recovery where WAL cannot be generated, leaves a clean
page clean.

Should the README correction be backpatched with the revert? The
misleading text is present in the back branches.

The revert leaves Alexey's original performance problem open. For
comparison, the recent VM clear fix c0d9864f5ce registered VM blocks in
heap WAL records. That does not transfer cheaply to FSM, since primary
and redo do not make matching FSM updates.

For master, I think Noah's second alternative is worth developing. It
would need to be a fork-wide contract rather than scattered
ZERO_ON_ERROR exceptions: every consumer must know how to discard or
reinitialize an invalid FSM page, and verification tools need an
explicit policy. I couldn't find a concrete proposal for that in the
thread, so this seems like separate work.

There are some other cases when we try to avoid FPIs...
Or perhaps this will all become simple once we have a double-write
buffer. :)

One small commit message fix:

s/everything else do so/everything else does so/

Thank you!

Best regards, Andrey Borodin.