> On 5 Oct 2020, at 14:14, Heikki Linnakangas <hlinn...@iki.fi> wrote:
>
> 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.
Agreed, now it makes sense to restart automatically.
> I would expect the checksums worker to be automatically started at postmaster
> startup. Can we make that happen?
A dynamic background worker has to be registered from a regular backend, so
it's not entirely clear to me where in startup processing that would take
place. Do you have any good suggestions?
cheers ./daniel
