Re: Can we avoid chdir'ing in resolve_symlinks() ?

From: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Can we avoid chdir'ing in resolve_symlinks() ?
Date: 2022-10-05 06:23:47
Message-ID: be8660d1-c191-92ad-af16-bd65f7b8e223@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 15.09.22 16:43, Tom Lane wrote:
> That seems ... a tad far-fetched, and even more to the point,
> it'd be the other package's fault not ours. We have never promised
> that those directories point to anyplace that's not PG-specific.
> I certainly do not buy that that's a good argument for breaking
> Postgres installation setups that work today.
>
> Also, there is nothing in that scenario that is in any way dependent
> on the use of symlinks, or even absolute paths, so I don't quite
> see the relevance to the current discussion.

Here is another variant of the same problem:

I have

$ which meson
/usr/local/bin/meson

Meson records its own path (somewhere under meson-info/ AFAICT), so it
can re-run itself when any of the meson.build files change. But since
the above is a symlink, it records its own location as
"/usr/local/Cellar/meson/0.63.1/bin/meson". So now, whenever the meson
package updates (even if it's just 0.63.0 -> 0.63.1), my build tree is
broken.

To clarify, this instance is not at all the fault of any code in
PostgreSQL. But it's another instance where resolving symlinks just
because we can causing problems.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2022-10-05 06:40:59 Re: [RFC] building postgres with meson - v13
Previous Message Peter Eisentraut 2022-10-05 06:16:37 Re: installcheck-world concurrency issues