Robert Haas <robertmhaas@gmail.com> writes:
> On Thu, Jan 7, 2010 at 11:39 AM, Tom Lane <tgl@sss.pgh.pa.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
