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

Hi,

On Wed, 29 Apr 2026 at 18:11, Daniel Gustafsson <daniel(at)yesql(dot)se> wrote:

> > On 28 Apr 2026, at 22:25, SATYANARAYANA NARLAPURAM <
> satyanarlapuram(at)gmail(dot)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