| From: | Daniel Gustafsson <daniel(at)yesql(dot)se> |
|---|---|
| To: | SATYANARAYANA NARLAPURAM <satyanarlapuram(at)gmail(dot)com> |
| Cc: | Ayush Tiwari <ayushtiwari(dot)slg01(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Tomas Vondra <tomas(at)vondra(dot)me>, 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-01 21:13:16 |
| Message-ID: | 525E0691-FDAD-4194-9228-592A2DB96749@yesql.se |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> On 1 May 2026, at 18:57, SATYANARAYANA NARLAPURAM <satyanarlapuram(at)gmail(dot)com> wrote:
> While further testing this feature, I realized that ProcessSingleRelationFork()
> unconditionally called log_newpage_buffer() for every page of every relation
> during pg_enable_data_checksums(). This included unlogged relations,
> which by definition never generate WAL for data changes and are reset to their
> init fork on any recovery.
>
> Guard the log_newpage_buffer() call with RelationNeedsWAL() so that
> unlogged relations still get their pages dirtied (ensuring the checksum
> is flushed to disk at the next checkpoint) but do not emit WAL.
>
> Attached a patch to address this and added a test for the same. My current
> test checks if standby has main fork, I could just checked WAL to verify this
> using pg_waldump. Any other test ideas are welcome.
Thanks for the report, I agree that this is an oversight that should be fixed.
Your patch looks good on first glance, I am travelling till Sunday evening so
will take another look when back in the office and will apply it then. Thanks!
--
Daniel Gustafsson
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Nathan Bossart | 2026-05-01 21:41:12 | Re: problems with toast.* reloptions |
| Previous Message | Nathan Bossart | 2026-05-01 20:10:51 | Re: bump minimum supported version of psql and pg_{dump,dumpall,upgrade} to v10 |