Hallo Michael,
I propose we re-read the control file for the enable case after we
finished operating on all files and (i) check the instance is still
offline and (ii) update the checksums version from there. That should be
a small but worthwhile change that could be done anyway.
That looks like a simple but mostly effective guard.
Another option would be to add a new feature which reliably blocks an
instance from starting up due to maintenance - either a new control file
field, some message in postmaster.pid (like "pg_checksums maintenance in
progress") that would prevent pg_ctl or postgres/postmaster from
starting up like 'FATAL: bogus data in lock file "postmaster.pid":
"pg_checksums in progress' or some other trigger file.
I think that a clear cluster-locking can-be-overriden-if-needed
shared-between-commands mechanism would be a good thing (tm), although it
requires some work.
My initial suggestion was to update the control file with an appropriate
state, eg some general "admin command in progress", but I understood that
it is rejected, and for another of your patch it seems that the
"postmaster.pid" file is the right approach. Fine with me, the point is
that it should be effective and consistent accross all relevant commands.
A good point about the "postmaster.pid" trick, when it does not contain
the posmaster pid, is that overriding is as simple as "rm postmaster.pid".
It could be possible to reach a state where the control file has
checksums enabled and some blocks are not correctly synced, still you
would notice rather quickly if the server is in an incorrect state at
the follow-up startup.
Would you? I think I'm with Fabien on this one and it seems worthwhile
to run fsync_pgdata() before and after update_controlfile() - the second
one should be really quick anyway.
Note that fsync_pgdata is kind of heavy, it recurses everywhere. I think
that a simple fsync on the control file only is enough.
Also, I suggest to maybe add a notice in verbose mode that we are
syncing the data directory - otherwise the user might wonder what's
going on at 100% done, though I haven't seen a large delay in my tests
so far.
I agree, as it might not be cheap.
--
Fabien.
