> On 28 Apr 2026, at 22:25, SATYANARAYANA NARLAPURAM > <[email protected]> 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. -- Daniel Gustafsson
v3-0008-Fix-data_checksum-GUC-show_hook.patch
Description: Binary data
v3-0007-Improve-database-detection-logic-in-datachecksums.patch
Description: Binary data
v3-0006-Improve-handling-of-concurrent-checksum-requests.patch
Description: Binary data
v3-0005-Typo-and-spelling-fixups-for-online-checksums.patch
Description: Binary data
v3-0004-Fix-invalid-checksum-state-transition-in-checkpoi.patch
Description: Binary data
v3-0003-Handle-data_checksum-state-changes-during-launche.patch
Description: Binary data
v3-0002-Test-improvements-for-online-checksums.patch
Description: Binary data
v3-0001-Prevent-pg_enable-disable_data_checksums-on-stand.patch
Description: Binary data
