Re: faster testing with symlink installs - Mailing list pgsql-hackers

From Tom Lane
Subject Re: faster testing with symlink installs
Date
Msg-id 14801.1520464635@sss.pgh.pa.us
Whole thread Raw
In response to Re: faster testing with symlink installs  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: faster testing with symlink installs  (Michael Paquier <michael@paquier.xyz>)
List 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 by date:

Previous
From: Robert Haas
Date:
Subject: Re: Two-phase update of restart_lsn in LogicalConfirmReceivedLocation
Next
From: Tom Lane
Date:
Subject: Re: Two-phase update of restart_lsn in LogicalConfirmReceivedLocation