Re: Bogus path in postmaster.opts

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Re: Bogus path in postmaster.opts
Дата
Msg-id 200601191906.31373.peter_e@gmx.net
обсуждение исходный текст
Ответ на Re: Bogus path in postmaster.opts  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Bogus path in postmaster.opts  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Tom Lane wrote:
> find_my_exec is not misbehaving: it's designed to expand symlinks,
> and would in fact be pretty useless if it did not.

I don't want to contest that in certain cases this is required but I can 
easily come up with scenarios (which perhaps no PostgreSQL user has 
encountered yet) where the currently behavior is broken.  One example 
is a GNU Stow like installation management where each package is 
installed in a private directory and the canonical locations 
in /usr/local are symlinks.  (It's altogether strange that this would 
distinguish between symbolic and hard links anyway, except that of 
course it cannot actually "resolve" hard links, since many installation 
schemes that one needs to cope with work the same with hard and soft 
links.)

> 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?

I don't know of one.  Something I have thought of during the recent 
options reorganization is that we could do away with the 
postmaster/postgres dichotomy altogether.  Just call the thing 
postmaster and give it a --single-user-mode option.

-- 
Peter Eisentraut
http://developer.postgresql.org/~petere/


В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Jim C. Nasby"
Дата:
Сообщение: Re: Surrogate keys (Was: enums)
Следующее
От: Josh Berkus
Дата:
Сообщение: Re: Surrogate keys (Was: enums)