Re: Bogus path in postmaster.opts

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Bogus path in postmaster.opts
Дата
Msg-id 17228.1137689621@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Bogus path in postmaster.opts  (Peter Eisentraut <peter_e@gmx.net>)
Ответы Re: Bogus path in postmaster.opts  (Peter Eisentraut <peter_e@gmx.net>)
Список 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 по дате отправления:

Предыдущее
От: Greg Stark
Дата:
Сообщение: Re: No heap lookups on index
Следующее
От: "Jonah H. Harris"
Дата:
Сообщение: Re: No heap lookups on index