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

On Tue, Sep 8, 2026 at 7:43 AM Andrey Borodin <x4mmm(at)yandex-team(dot)ru> 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