Horton

Re: Changing the state of data checksums in a running cluster

SATYANARAYANA NARLAPURAM <satyanarlapuram@gmail.com>

View thread
From: SATYANARAYANA NARLAPURAM <satyanarlapuram@gmail.com>
To: Daniel Gustafsson <daniel@yesql.se>
Cc: Ayush Tiwari <ayushtiwari.slg01@gmail.com>, Tomas Vondra <tomas@vondra.me>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Heikki Linnakangas <hlinnaka@iki.fi>, Andres Freund <andres@anarazel.de>, Bernd Helmle <mailings@oopsware.de>, Michael Paquier <michael@paquier.xyz>, Michael Banck <mbanck@gmx.net>
Date: 2026-05-05T19:19:00Z
Lists: pgsql-hackers 
Hi

On Tue, May 5, 2026 at 12:08 PM Daniel Gustafsson <daniel@yesql.se> wrote:

> > On 5 May 2026, at 17:21, Ayush Tiwari <ayushtiwari.slg01@gmail.com>
> wrote:
>
> > I've a small concern in 0001.  The new guard uses only
> RelationNeedsWAL(reln),
> > but ProcessSingleRelationByOid() iterates all forks.  For unlogged
> relations,
> > the init fork is special, there are several existing call sites that
> preserve
> > WAL for INIT_FORKNUM, for example using
> >
> >   RelationNeedsWAL(rel) || forknum == INIT_FORKNUM
> >
> > and catalog/storage.c notes that unlogged init forks need WAL and sync.
> >
> > So I think the condition in ProcessSingleRelationFork() should preserve
> the
> > init-fork case, e.g.
> >
> >   if (RelationNeedsWAL(reln) || forkNum == INIT_FORKNUM)
> >       log_newpage_buffer(buf, false);
>
> Which failure scenario are you thinking about here?  When dealing with the
> catalog relation I can see the need but here we are reading, and writing,
> data
> pages.  In which case would we need to issue an FPI for an unlogged
> relation
> init fork? I might be missing something obvious here.


Good catch,IIUC init page has valid checksum and when we set checksum on
primary I think we need to pass it to standby. Otherwise, after failover we
may see invalid checksum for unlogged relations. I haven’t validated it,
will test it and update the patch.