Hello Andres,
I think putting this into the control file is a seriously bad idea. Postmaster interlocks against other postmasters running via postmaster.pid.
Having a second interlock mechanism, in a different file, doesn't make any sort of sense. Nor does it seem sane to have external tool write over data as INTENSELY critical as the control file, when they then have to understand CRCs etc.
On this point, there are functions for that, get/update_controlfile, so this should be factored out.
The initial insentive for raising the issue, probably in the wrong thread and without a clear understanding of the matter, is that I've been reviewing a patch to enable/disable checksums on a stopped cluster.
The patch updates all the checksums in all the files, and changes the control file to tell that there are checksums. Currently it checks and creates a fake "posmaster.pid" file to attempt to prevent another tool to run concurrently to this operation, with ISTM a procedure prone to race conditions thus does not warrant that it would be the only tool running on the cluster. This looked to me as a bad hack. Given that other command that take on a cluster seemed to use the controlfile to signal that they are doing something, I'd thought that it would be the way to go, but then I noticed that the control file read/write procedure looks as bad as the postmaster.pid hack to ensure that only one command is active.
Nevertheless, I'm ranting in the wrong thread and it seems that these is no real problem to solve, so I'll say fine to the to-me-unconvincing "postmaster.pid" hack proposed in the patch.
-- Fabien.
