Replying to an older message in this thread:
>> + /*
>> + * If we reach this point with checksums in inprogress state, we notify
>> + * the user that they need to manually restart the process to enable
>> + * checksums. This is because we cannot launch a dynamic background worker
>> + * directly from here, it has to be launched from a regular backend.
>> + */
>> + if (ControlFile->data_checksum_version == PG_DATA_CHECKSUM_INPROGRESS_VERSION)
>> + ereport(WARNING,
>> + (errmsg("checksum state is \"inprogress\" with no worker"),
>> + errhint("Either disable or enable checksums by calling the
>> pg_disable_data_checksums() or pg_enable_data_checksums()
>> functions.")));
>>
>> This seems pretty half-baked.
>
> I don't disagree with that. However, given that enabling checksums is a pretty
> intensive operation it seems somewhat unfriendly to automatically restart. As
> a DBA I wouldn't want that to kick off without manual intervention, but there
> is also the risk of this being missed due to assumptions that it would restart.
> Any ideas on how to treat this?
>
> If/when we can restart the processing where it left off, without the need to go
> over all data again, things might be different wrt the default action.
The later patch version do support restarting, so I think we should
revisit this issue. I would expect the checksums worker to be
automatically started at postmaster startup. Can we make that happen?
- Heikki