Horton

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

Daniel Gustafsson <daniel@yesql.se>

View thread
From: Daniel Gustafsson <daniel@yesql.se>
To: Ayush Tiwari <ayushtiwari.slg01@gmail.com>
Cc: SATYANARAYANA NARLAPURAM <satyanarlapuram@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:08:30Z
Lists: pgsql-hackers 
> 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.

> 0002 and 0003 look good to me.

Thanks for looking!

--
Daniel Gustafsson