From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
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: | 2023-03-22 19:52:29 |
Message-ID: | 1653267.1679514749@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> writes:
> On 05.10.22 15:59, Tom Lane wrote:
>> What did you think of the compromise proposal to change only
>> the paths that pg_config outputs? I've not tried to code that,
>> but I think it should be feasible.
> I don't think I understand what this proposal actually means. What
> would be the behavior of pg_config and how would it be different from
> before?
What I had in mind was:
* server and most frontend programs keep the same behavior, that is
fully resolve their executable's path to an absolute path (and then
navigate to the rest of the installation from there); but now they'll
use realpath() to avoid chdir'ing while they do that.
* pg_config applies realpath() if its initial PATH search produces a
relative path to the executable, or if the last component of that path
is a symlink. Otherwise leave it alone, which would have the effect of
not expanding directory-level symlinks.
I think that changing pg_config's behavior would be enough to resolve
the complaints you listed, but perhaps I'm missing some fine points.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Davis | 2023-03-22 19:53:18 | Re: Non-superuser subscription owners |
Previous Message | Daniel Gustafsson | 2023-03-22 19:38:09 | Re: On login trigger: take three |