>> Ok, this might not work, because of the following, less likely, race
>> condition:
>>
>> postmaster opens control file RW
>> pg_checksums moves control file, postmater open file handle follows
>> ...
>>
>> So ISTM that we really need some locking to have something clean.
>
> We are talking about complicating a method which is already fine for a
> a window where the whole operation works, as it could take hours to
> enable checksums, versus a couple of instructions. I am not sure that
> it is worth complicating the code more.
Hmmm. Possibly. The point is that anything only needs to be implemented
once. The whole point of pg is to have ACID transactional properties, but
it does not achieve that on the controlfile, which I find paradoxical:-)
Now if there is a race condition opportunity, ISTM that it should be as
short as possible. Renaming before manipulating seems safer if other
commands proceeds like that as well. Probably if pg always rename *THEN*
open before doing anything in all commands it could be safe, provided that
the renaming is atomic, which I think is the case.
That would avoid locking, at the price of a small probability of having a
controlfile in a controlfile.command-that-failed-at-the-wrong-time state.
Maybe it is okay. Maybe there is a need to be able to force the
state back to something to recover from such unlikely event, but probably
it does already exists (eg postmaster could be dead without releasing the
controlfile state).
--
Fabien.