From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | Larry Rosenman <ler(at)lerctr(dot)org>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Idea: cross-check versions during initdb |
Date: | 2000-10-27 22:40:06 |
Message-ID: | 5494.972686406@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
>> But it's still dependent on the user's PATH to point to the right
>> executables, no?
> This is what's puzzling me. There's code in there that tries to locate
> initdb and uses the executables and bki files (7.0 only) from the same
> tree.
Yeah, but how long has that code been in there? Wouldn't be at all
surprised if the complaints are coming from people who are managing
to invoke a 6.5 initdb script against 7.0 postgres executable and/or
library files.
Of course, people who manage to invoke a 6.5 or 7.0 initdb script aren't
going to be helped anyway by defenses we put into 7.1 initdb :-(.
Perhaps there need to be additional crosschecks performed by the
postgres executable to ensure that (a) it's being called by a compatible
initdb and (b) it's being fed compatible bki files.
Point b could be addressed if we put version IDs into the bki files and
have BootstrapMain check for them. As for point a, maybe we could extend
the bootstrap switch set so that it includes a version number passed by
the initdb script; then BootstrapMain refuses to play unless the correct
version number is supplied. This would work if old postgres executables
reject the version# info as an invalid switch ...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2000-10-27 22:41:50 | Re: Summary: what to do about INET/CIDR |
Previous Message | Larry Rosenman | 2000-10-27 22:37:32 | Re: Summary: what to do about INET/CIDR |