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