Robert Haas <robertmh...@gmail.com> writes: > On Thu, Jan 7, 2010 at 11:39 AM, Tom Lane <t...@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 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs