pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Noah Misch <noah@leadboat.com>
To: Alexander Korotkov <aekorotkov@gmail.com>
Cc: Melanie Plageman <melanieplageman@gmail.com>
Cc: Alexey Makhmutov <a.makhmutov@postgrespro.ru>
Cc: Andrey Borodin <x4mmm@yandex-team.ru>
Cc: pgsql-hackers@postgresql.org
Subject: Re: Two issues leading to discrepancies in FSM data on the standby server
Date: Sun, 13 Sep 2026 10:21:23 -0700
Message-ID: <20260913172123.89.noahmisch@microsoft.com> (raw)
In-Reply-To: <CAPpHfdvdS3ny25_2korU=WQqLrP8-CK42b-2ga6qh6Fk4pmEUw@mail.gmail.com>
References: <596c4f1c-f966-4512-b9c9-dd8fbcaf0928@postgrespro.ru>
	<6A6138F4-8D6F-463D-9ECC-38C0881308FE@yandex-team.ru>
	<60b79f39-69e5-4c73-a708-6ef1fd5e7980@postgrespro.ru>
	<CAAKRu_Yj5DgvwAEHgM1PkoueQE0s7JSbs+XHO=oFj1Y+pzVJ3A@mail.gmail.com>
	<CAPpHfdv181MSf8-5mDm8+x9i02CWn=B6vMj5ATTpCbChu5co3w@mail.gmail.com>
	<20260901211837.f6.noahmisch@microsoft.com>
	<CAAKRu_aLa5pbjPaTVdNOWpCN8zMJbLfse-FsS+PgBetyTSdCFw@mail.gmail.com>
	<CAPpHfdv6mC8ZH5B-+2OKjLuqpC_8H+KctMy2Caxoi5Q7_3VSFA@mail.gmail.com>
	<20260912200540.1b.noahmisch@microsoft.com>
	<CAPpHfdvdS3ny25_2korU=WQqLrP8-CK42b-2ga6qh6Fk4pmEUw@mail.gmail.com>

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@leadboat.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.






view thread (21+ messages)  latest in thread

Message-ID: <20260913172123.89.noahmisch@microsoft.com>
Permalink:  ../20260913172123.89.noahmisch@microsoft.com/
Also on:    postgresql.org/message-id/20260913172123.89.noahmisch@microsoft.com

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: noah@leadboat.com, aekorotkov@gmail.com, melanieplageman@gmail.com, a.makhmutov@postgrespro.ru, x4mmm@yandex-team.ru
  Subject: Re: Two issues leading to discrepancies in FSM data on the standby server
  In-Reply-To: <20260913172123.89.noahmisch@microsoft.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox