On Tue, Sep 8, 2026 at 7:43 AM Andrey Borodin <[email protected]> wrote: > 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've pushed the revert. > 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. Didn't yet pushed the README. I wish it have more review. > Should the README correction be backpatched with the revert? The > misleading text is present in the back branches. Not sure we necessarily need this. Whoever would try to fix this should start from exploring master. > 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. Yes, that should be separate and rather bigger work on master. > 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/ That was applied before commit. ------ Regards, Alexander Korotkov Supabase
