Skip site navigation (1) Skip section navigation (2)

Re: BUG #5267: initdb fails on AIX: could not identify current directory

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Michael Felt <mamfelt(at)gmail(dot)com>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #5267: initdb fails on AIX: could not identify current directory
Date: 2010-01-07 18:43:29
Message-ID: 29498.1262889809@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-bugs
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Thu, Jan 7, 2010 at 11:39 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> How does that help? We still can't print the directory name.

> Well, as it is, it looks like the failure of getcwd() might be an
> incidental problem, and the inability to find postgres was what sunk
> the ship.  In fact, the inability to find postgres is an entirely
> illusory problem created by the failure of getcwd().  If you just got
> one error message saying "getcwd failed", I think it would be more
> clear what the problem was.  I had to go read the code to figure out
> that the failure of getcwd() would result in a guaranteed failure to
> find the postgres executable.

Should we just turn find_my_exec() into a routine that elogs/exits on
failure, instead of returning an error code?  There are a couple of call
sites that have the idea that they can survive a failure, but I think
they're pretty bogus.

There are actually two distinct cases that we need to worry about (and
I'm not entirely certain that I know which one Michael is hitting).
Case 1 is where getcwd() fails on the program's starting current
directory.  Case 2 is where it fails after we do a series of chdir's
following symlinks.  In case 1 there really is no additional information
available, whereas in case 2 we could perhaps print the name of the
first or last symlink we tried to follow.  Also, while I think it might
be fair to treat case 1 as a hard error, it's a bit more plausible that
a caller might have a recovery strategy for case 2.  So maybe treating
these two cases differently would be a good thing.

			regards, tom lane

In response to

Responses

pgsql-bugs by date

Next:From: Mike LandisDate: 2010-01-07 20:20:58
Subject: Re: BUG #5268: PQgetvalue incorrectly returns 0
Previous:From: Robert HaasDate: 2010-01-07 18:18:08
Subject: Re: BUG #5098: Levenshtein with costs is broken

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group