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.
