Thread: Idea: cross-check versions during initdb
While answering the n'th why-is-initdb-failing question that looked like
a version mismatch problem, it occurred to me to wonder why we don't
make initdb verify that the executable and library files it's using
are all from the same release it is. I think this would eliminate an
installation mistake that's practically reached FAQ status.
A sketch of a way to do this is:
1. Add a --version switch to postgres or postmaster to print its version
and exit. Then initdb could check the executable's version against its
own. (Alternatively we could rely on pg_config, but at a minimum that
would mean checking to make sure that pg_config is found in the same
directory that postgres is in. A direct check on the key executable
seems a lot safer.)
2. During "make install", generate a PGVERSION file and store it in the
same directory that global.bki etc are stored in (the .../share install
directory). initdb could look for this to ensure that PGLIB is pointing
to a compatible library directory. Alternatively, add version info as
a comment in the first line of global.bki.
I don't have time to pursue this right now, but maybe someone else would
like to pick up on it.
regards, tom lane
Sounds like an easy one for a newbie to pick up. Let me look at it, but I think I'd like dibs on it. LER * Tom Lane <tgl@sss.pgh.pa.us> [001026 13:29]: > While answering the n'th why-is-initdb-failing question that looked like > a version mismatch problem, it occurred to me to wonder why we don't > make initdb verify that the executable and library files it's using > are all from the same release it is. I think this would eliminate an > installation mistake that's practically reached FAQ status. > > A sketch of a way to do this is: > > 1. Add a --version switch to postgres or postmaster to print its version > and exit. Then initdb could check the executable's version against its > own. (Alternatively we could rely on pg_config, but at a minimum that > would mean checking to make sure that pg_config is found in the same > directory that postgres is in. A direct check on the key executable > seems a lot safer.) > > 2. During "make install", generate a PGVERSION file and store it in the > same directory that global.bki etc are stored in (the .../share install > directory). initdb could look for this to ensure that PGLIB is pointing > to a compatible library directory. Alternatively, add version info as > a comment in the first line of global.bki. > > I don't have time to pursue this right now, but maybe someone else would > like to pick up on it. > > regards, tom lane -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 (voice) Internet: ler@lerctr.org US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
Added to TODO: * Prevent initdb from running wrong version of postmaster/postgres > While answering the n'th why-is-initdb-failing question that looked like > a version mismatch problem, it occurred to me to wonder why we don't > make initdb verify that the executable and library files it's using > are all from the same release it is. I think this would eliminate an > installation mistake that's practically reached FAQ status. > > A sketch of a way to do this is: > > 1. Add a --version switch to postgres or postmaster to print its version > and exit. Then initdb could check the executable's version against its > own. (Alternatively we could rely on pg_config, but at a minimum that > would mean checking to make sure that pg_config is found in the same > directory that postgres is in. A direct check on the key executable > seems a lot safer.) > > 2. During "make install", generate a PGVERSION file and store it in the > same directory that global.bki etc are stored in (the .../share install > directory). initdb could look for this to ensure that PGLIB is pointing > to a compatible library directory. Alternatively, add version info as > a comment in the first line of global.bki. > > I don't have time to pursue this right now, but maybe someone else would > like to pick up on it. > > regards, tom lane > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Peter Eisentraut <peter_e@gmx.net> writes:
> Bonus project: find out why initdb is picking up the wrong files in the
> first place.
User error is a sufficient explanation in the cases I've seen: wrong
postgres executable found first in PATH, PGLIB or -L pointing to wrong
place, etc.
The changes you've made since 7.0 may reduce the incidence of mistakes,
but they won't eliminate them...
regards, tom lane
> > 1. Add a --version switch to postgres or postmaster to print its version > > and exit. postmaster already has this. Someone can copy the code into tcop/postgres.c as well. But should we not use the catversion for this? > > to a compatible library directory. Alternatively, add version info as > > a comment in the first line of global.bki. I think that's better. Bonus project: find out why initdb is picking up the wrong files in the first place. -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
Peter Eisentraut <peter_e@gmx.net> writes:
> Actually, initdb of 7.1 gets the directory location of the bootstrap files
> wired in at build time. The only way to override it is to use the -L
> option. So the problem seems a lot less grave that way.
That does seem to reduce the odds of wrong-bki-files considerably.
But it's still dependent on the user's PATH to point to the right
executables, no?
regards, tom lane
> Peter Eisentraut <peter_e@gmx.net> writes: > > Bonus project: find out why initdb is picking up the wrong files in the > > first place. > > User error is a sufficient explanation in the cases I've seen: wrong > postgres executable found first in PATH, PGLIB or -L pointing to wrong > place, etc. > > The changes you've made since 7.0 may reduce the incidence of mistakes, > but they won't eliminate them... My guess is that the have some PostgreSQL binaries in /usr/local/bin and pgsql/bin, and their path has one prefered over the other. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Larry Rosenman writes: > Sounds like an easy one for a newbie to pick up. Let me look at it, > but I think I'd like dibs on it. Actually, initdb of 7.1 gets the directory location of the bootstrap files wired in at build time. The only way to override it is to use the -L option. So the problem seems a lot less grave that way. -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
Peter Eisentraut <peter_e@gmx.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
Tom Lane 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. Evidently this code does not always work right, but that's what
needs to be fixed.
CMDNAME=`basename $0`
...
#
# Find out where we're located
#
if echo "$0" | grep '/' > /dev/null 2>&1
then # explicit dir name given PGPATH=`echo $0 | sed 's,/[^/]*$,,'` # (dirname command is not
portable)
else # look for it in PATH ('which' command is not portable) for dir in `echo "$PATH" | sed 's/:/ /g'`
do # empty entry in path means current dir [ -z "$dir" ] && dir='.' if [ -f
"$dir/$CMDNAME"] then PGPATH="$dir" break fi
done
fi
--
Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
Tom Lane writes: > 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 :-(. It just occured to me that people invoking pre-7.1 initdbs with new input files are not going to get very far because the bki files have different names now. They could still use a new backend with old bki files, though. We could work around that if we subtly mangle the options set of "postgres". For example, the -C option is pretty useless. Nobody cares about vital pieces of information like POSTGRES backend interactive interface $Revision: 1.183 $ $Date: 2000/10/28 01:07:00 $ We could make postgres print a message like "Are you sure you're not invoking me from an old initdb?" upon its receipt, since old initdb versions pass this option. As for "new initdb using old stuff", I'm putting a check into initdb for `postgres --version`, which should make it safe. The danger of accidentally using old bki files is not a problem at this point, but a future version of genbki.sh might want to put a simple # PostgreSQL 7.2 line atop its output files which initdb can check for. That should be pretty low-interference. -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
Peter Eisentraut <peter_e@gmx.net> writes:
> Tom Lane writes:
>> 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 :-(.
> It just occured to me that people invoking pre-7.1 initdbs with new input
> files are not going to get very far because the bki files have different
> names now.
OK, but that will only protect us for the 7.0 to 7.1 transition. Future
transitions will create the risk again. I think we should try to solve
these issues now while we're thinking about them.
> a future version of genbki.sh might want to put a simple
> # PostgreSQL 7.2
> line atop its output files which initdb can check for.
Seems like a plan to me.
regards, tom lane