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.
