>> For enable/disable, while the command is running, it should mark the
>> cluster as opened to prevent an unwanted database start. I do not see
>> where this is done.
>>
>> You have pretty much the same class of problems if you attempt to
>> start a cluster on which pg_rewind or the existing pg_verify_checksums
>> is run after these have scanned the control file to make sure that
>> they work on a cleanly-stopped instance. [...]
>
> I think it comes down to what the outcome is. If we're going to end up with
> a corrupt database (e.g. one where checksums aren't set everywhere but they
> are marked as such in pg_control) then it's not acceptable. If the only
> outcome is the tool gives an error that's not an error and if re-run it's
> fine, then it's a different story.
ISTM that such an outcome is indeed a risk, as a starting postgres could
update already checksummed pages without putting a checksum. It could be
even worse, although with a (very) low probability, with updates
overwritten on a race condition between the processes. In any case, no
error would be reported before much later, with invalid checksums or
inconsistent data, or undetected forgotten committed data.
--
Fabien.
