Re: Bogus path in postmaster.opts - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Bogus path in postmaster.opts
Date
Msg-id 17228.1137689621@sss.pgh.pa.us
Whole thread Raw
In response to Bogus path in postmaster.opts  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: Bogus path in postmaster.opts  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
Peter Eisentraut <peter_e@gmx.net> writes:
> Earlier, CreateOptsFile was called with argv, now it's passed the result of 
> find_my_exec instead.  I'm not sure whether that change was wrong to begin 
> with or whether find_my_exec is mishaving (it should return something 
> containing "postmaster", no?).

find_my_exec is not misbehaving: it's designed to expand symlinks, and
would in fact be pretty useless if it did not.  We could go back to
storing the raw value of argv[0] in the opts file, but I rather like
having the full path in there.

There is another possible answer, and it's something I've been meaning
to bring up for awhile.  Is there a good reason why postmaster is a
symlink to postgres, rather than a hard link?  Surely the symlink way
is not any more efficient.  The thing that ticks me off about this
is that it confuses gdb: if you say "gdb postmaster" and then "run",
what gets passed as argv[0] is "postgres", thus breaking your test.
So I not infrequently find myself manually replacing the symlink with
a hard link in order to be able to test.  If it'd result in nicer
output in the opts file too, then all the more reason to change.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Greg Stark
Date:
Subject: Re: No heap lookups on index
Next
From: "Jonah H. Harris"
Date:
Subject: Re: No heap lookups on index