Horton
Menu

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

Ayush Tiwari <ayushtiwari.slg01@gmail.com>

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

On Wed, 29 Apr 2026 at 18:11, Daniel Gustafsson <daniel@yesql.se> wrote:

> > On 28 Apr 2026, at 22:25, SATYANARAYANA NARLAPURAM <
> satyanarlapuram@gmail.com> wrote:
>
> > Should we update ControlFile->data_checksum_version at the
> end-of-recovery? If not, the disk
> > is stale compared to in memory until the next checkpoint. The code two
> lines below updates
> > the control file anyways to set the DB_IN_PRODUCTION. Maybe combine the
> update with that?
> > It's no big deal if we don't do it because it will be self correct but
> tools like pg_controldata
> > give stale value for some time.
>
> I've been thinking about this one and in the end went with adding it.  It
> is
> written already with PerformRecoveryXLogAction but we might have an
> inprogress-off->off transition after that which seems better to reflect in
> the
> controlfile.
>
> Also, an off-list question on yesterday's bugfix made me realize that it
> can be
> simplified even further.  Instead of tracking which processes need cleanup
> in
> the exit handler, we can simply defer installing it at all till we know
> that
> there will be cleanup to process.
>
> The attached also updates the commit messages to reflect the reviewers of
> this
> patchset as well as email id's.
>
>
Thanks for the updated patchset. I applied v3 on top of current master and
did
a focused review/test pass.

Reran the duplicate-launcher reproducer three times against v3 with a more
aggressive variant, could not see any issue.

The v3 launcher_exit change looks good to me. Deferring installation of the
on_shmem_exit() handler until after the process has confirmed that it owns
the
launcher role avoids the duplicate-launcher cleanup problem.

I also looked at the end-of-recovery control-file update. Copying
XLogCtl->data_checksum_version into ControlFile->data_checksum_version under
ControlFileLock before the existing UpdateControlFile() call is a good idea.

The patchset looks good.

Regards,
Ayush

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Use correct datatype for PID

  2. Improve comments in online checksums code

  3. Fix checksum state transition during promotion

  4. Fix regex searching for page verification failures in tests

  5. Apply data-checksum worker throttling parameters

  6. Skip WAL for unlogged main fork during online checksum enable

  7. Fix data_checksum GUC show_hook

  8. Improve database detection logic in datachecksumsworker

  9. Improve handling of concurrent checksum requests

  10. Typo and spelling fixups for online checksums

  11. Fix invalid checksum state transition in checkpoints

  12. Handle data_checksum state changes during launcher_exit

  13. Test improvements for online checksums

  14. Prevent pg_enable/disable_data_checksums() on standby

  15. Test stabilization for online checksums

  16. Make data checksum tests more resilient for slow machines

  17. Formalize WAL record for XLOG_CHECKPOINT_REDO

  18. Revert "Get rid of WALBufMappingLock"

  19. Get rid of WALBufMappingLock

  20. Improve grammar of options for command arrays in TAP tests