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

Update: I have reinstalled my server and now it works fine. (I did not
recomply the initdb program).
As I did this to enable a security feature, not related to this (called
Trusted Executition) I can only guess what might have been to problem. As I
dont have the old system - and I am not going to reinstall it to "test" - we
are at a dead end here.

I am glad that my build procedure worked properly though!

I am looking for other AIX users to test the build as I am building up a
repository of pre-built AIX open source packages - especially those not
found elsewhere.

Where can I best make this known within postgres?

Thanks for your assistance,
Michael

On Mon, Jan 11, 2010 at 8:37 AM, Michael Felt <mamfelt(at)gmail(dot)com> wrote:

> Are you still thinking about this - and what might be the problem?
>
> In any case I am not starting from an orphaned directory. I have started
> from postgres home directory and /tmp as requested. The audit log I sent
> shows that initdb has performed at least one chdir command.
>
> Michael
>
>
> On Fri, Jan 8, 2010 at 4:59 AM, Michael Felt <mamfelt(at)gmail(dot)com> wrote:
>
>> is there a debug or trace mode wherein the system reports all its
>> activity? Perhaps a compile time option?
>>
>>
>> On Thu, Jan 7, 2010 at 7:43 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>
>>> 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
>>>
>>
>>
>