| From: | Daniel Gustafsson <daniel(at)yesql(dot)se> |
|---|---|
| To: | Ayush Tiwari <ayushtiwari(dot)slg01(at)gmail(dot)com> |
| Cc: | SATYANARAYANA NARLAPURAM <satyanarlapuram(at)gmail(dot)com>, Tomas Vondra <tomas(at)vondra(dot)me>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Andres Freund <andres(at)anarazel(dot)de>, Bernd Helmle <mailings(at)oopsware(dot)de>, Michael Paquier <michael(at)paquier(dot)xyz>, Michael Banck <mbanck(at)gmx(dot)net> |
| Subject: | Re: Changing the state of data checksums in a running cluster |
| Date: | 2026-05-05 19:08:30 |
| Message-ID: | 1EF07DE7-ED45-4FF1-9571-424BAD15151F@yesql.se |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> On 5 May 2026, at 17:21, Ayush Tiwari <ayushtiwari(dot)slg01(at)gmail(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ayush Tiwari | 2026-05-05 19:18:53 | Re: Changing the state of data checksums in a running cluster |
| Previous Message | Alexander Lakhin | 2026-05-05 19:00:00 | Re: Improving tracking/processing of buildfarm test failures |