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.
