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

On Sun, Sep 13, 2026 at 8:21 PM Noah Misch <noah(at)leadboat(dot)com> wrote:
> On Sun, Sep 13, 2026 at 03:10:58PM +0300, Alexander Korotkov wrote:
> > On Sat, Sep 12, 2026 at 11:05 PM Noah Misch <noah(at)leadboat(dot)com> wrote:
> > > On Mon, Sep 07, 2026 at 06:22:22PM +0300, Alexander Korotkov wrote:
> > > > 0002 is patch for FSM readme to highlight this aspect
> > > >
> > > > I'm going to push (and backpatch) 0001. 0002 needs review.
> > >
> > > > Subject: [PATCH v1 2/2] Say in the FSM README why its hint writes still need
> > > > full page images
> > >
> > > > +That RBM_ZERO_ON_ERROR is a property of this directory, not of the FSM fork
> > > > +itself. The files themselves are ordinary relation files, and plenty of code
> > > > +outside freespace.c reads them and does verify checksums:
> > > > +RelationCopyStorage(), which ALTER TABLE ... SET TABLESPACE runs over every
> > > > +fork; the read stream in RelationCopyStorageUsingBuffer(), used by
> > > > +CREATE DATABASE ... STRATEGY = wal_log; and the checksum verification in base
> > > > +backups and in pg_checksums. The last two are the reason this cannot simply be
> > > > +relaxed: an external verification tool has no way to tell a tear that we
> > > > +consider harmless from one caused by failing storage, so making it accept
> > > > +the former blinds it to the latter.
> > >
> > > One could relax the "last two" by having those tools skip checksum
> > > verification for *_fsm files, so let's not claim it's infeasible. It's true
> > > that this could miss failing-storage evidence that coincidentally landed in
> > > FSM, but accepting that could be the right thing someday. Other than that, I
> > > agree with this README change. Thanks.
> >
> > I've corrected that paragraph. I'm going to push this to master if no
> > objections.
>
> > +That RBM_ZERO_ON_ERROR is a property of this directory, not of the FSM fork
> > +itself. The files themselves are ordinary relation files, and plenty of code
> > +outside freespace.c reads them and does verify checksums:
> > +RelationCopyStorage(), which ALTER TABLE ... SET TABLESPACE runs over every
> > +fork; the read stream in RelationCopyStorageUsingBuffer(), used by
> > +CREATE DATABASE ... STRATEGY = wal_log; and the checksum verification in base
> > +backups and in pg_checksums. The last two could instead be taught to skip
> > +*_fsm files, and that may be the right call someday. The cost would be that
> > +a tool told to ignore a tear in the FSM can no longer report one caused by
> > +failing storage. Today they do verify, so what we write here has to be
> > +valid.
>
> I'd handle the last sentences differently, yielding a paragraph like this:
>
> That RBM_ZERO_ON_ERROR is a property of this directory, not of the FSM fork
> itself. The files themselves are ordinary relation files, and plenty of code
> outside freespace.c reads them and does verify checksums:
> RelationCopyStorage(), which ALTER TABLE ... SET TABLESPACE runs over every
> fork; the read stream in RelationCopyStorageUsingBuffer(), used by CREATE
> DATABASE ... STRATEGY = wal_log; and the checksum verification in base backups
> and in pg_checksums. The alternative would be all such code skipping checksum
> validation of *_fsm files, and that may be the right call someday. Today they
> do verify, so what we write here has to be valid.

Pushed to master with your corrections.

------
Regards,
Alexander Korotkov
Supabase