Kevin Brown wrote:
If we're truly concerned about the possibility of multiple installations attempting to use the same config, then the answer is simple: require that the location of the config file be specified on the command line and don't compile a default location into the binary. Similarly, don't take the value from an environment variable.
Packaged installations won't have trouble with this: they supply a startup script which would pass the appropriate argument to the postmaster.
In order to keep with existing practice, you could say that you have to supply *either* a config file, which points to the data dir etc., *or* a data dir, in which case the config files must be in the data dir. I very much agree with the idea of not compiling in a default config file location.
If we want to be a bit paranoid (justifiable if you've got really important data on the line), we could also require that a version string exist in the config file. If the version string doesn't match the version of the postmaster being started, the postmaster exits with an error (and a hint of what to set the version string to and what the name of the version string parameter is). That way, even if you screw up on the command line, you won't hose a database by starting the wrong version of the postmaster against it. Not sure if this would break anything, though.
It won't start now if there's a version mismatch, and that's nothing whatever to do with the config file - it matches against the PG_VERSION file. We're already rightly paranoid on this point.
cheers
andrew
---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
