Re: faster testing with symlink installs

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: faster testing with symlink installs
Дата
Msg-id 14801.1520464635@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: faster testing with symlink installs  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: faster testing with symlink installs  (Michael Paquier <michael@paquier.xyz>)
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Wed, Feb 28, 2018 at 9:34 PM, Peter Eisentraut
> <peter.eisentraut@2ndquadrant.com> wrote:
>> Except ... this doesn't actually work.  find_my_exec() resolves symlinks
>> to find the actual program installation, and so for example the
>> installed initdb will look for postgres in src/bin/initdb/.  I would
>> like to revert this behavior, because it seems to do more harm than
>> good.  The original commit message indicates that this would allow
>> symlinking a program to somewhere outside of the installation tree and
>> still allow it to work and find its friends.  But that could just as
>> well be done with a shell script.

> My initial gut feeling is that changing this would hurt more people
> than it would help.

I agree.  My recollection is that we expended substantial sweat to make
that type of setup work, and I do not think it was for idle reasons.
The fact that the behavior is very old doesn't mean it was a bad choice.
(Also, the fact that the commit message didn't explain the reasoning in
detail is not much of an argument; we didn't go in for that back then.)

            regards, tom lane


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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Two-phase update of restart_lsn in LogicalConfirmReceivedLocation
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Two-phase update of restart_lsn in LogicalConfirmReceivedLocation