Hi On Tue, May 5, 2026 at 12:08 PM Daniel Gustafsson <[email protected]> wrote:
> > On 5 May 2026, at 17:21, Ayush Tiwari <[email protected]> > 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.
