From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: why does find_my_exec resolve symlinks? |
Date: | 2015-02-14 16:41:36 |
Message-ID: | 28492.1423932096@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> Here is a scenario:
> ./configure --prefix=/usr/local/pgsql/9.4.1
> make
> make install
> ln -s 9.4.1 /usr/local/pgsql/9.4
> PATH=/usr/local/pgsql/9.4/bin:$PATH
> And then when 9.4.2 comes out, the symlink is updated.
> I think this sort of setup in variations is not uncommon.
If it were all that common, we'd have heard people complaining before.
> The reason for this behavior is
> commit 336969e490d71c316a42fabeccda87f798e562dd
> Author: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
> Date: Sat Nov 6 23:06:29 2004 +0000
> Add code to find_my_exec() to resolve a symbolic link down to the
> actual executable location. This allows people to continue to use
> setups where, eg, postmaster is symlinked from a convenient place.
> Per gripe from Josh Berkus.
> I don't quite understand what setup Josh was using there.
IIRC, the idea was that /usr/bin/postgres might be a symlink to
/usr/local/pgsql/9.4.1/bin/postgres. If we stop resolving symlinks,
that type of arrangement will break :-(. Given that it's been like
this for ten years without previous complaints, I'm disinclined to
mess with it ...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2015-02-14 16:56:50 | Re: chkpass with RANDOMIZE_ALLOCATED_MEMORY |
Previous Message | Tom Lane | 2015-02-14 15:45:17 | Re: Manipulating complex types as non-contiguous structures in-memory |