Peter Eisentraut <[EMAIL PROTECTED]> 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
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
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 r
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 probl
Peter Eisentraut <[EMAIL PROTECTED]> 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, b
> Peter Eisentraut <[EMAIL PROTECTED]> 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, e
Peter Eisentraut <[EMAIL PROTECTED]> 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-b
> > 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
Peter Eisentraut <[EMAIL PROTECTED]> 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 chang
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 usin
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 <[EMAIL PROTECTED]> [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 do
11 matches
Mail list logo
