From: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Expand the use of check_canonical_path() for more GUCs |
Date: | 2020-06-02 09:04:42 |
Message-ID: | 44af92e9-7458-14d6-01e7-5bcd0b3adaec@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2020-05-29 19:24, Robert Haas wrote:
> On Tue, May 19, 2020 at 7:02 AM Peter Eisentraut
> <peter(dot)eisentraut(at)2ndquadrant(dot)com> wrote:
>> That thread didn't resolve why check_canonical_path() is necessary
>> there. Maybe the existing uses could be removed?
>
> This first sentence of this reply seems worthy of particualr
> attention. We have to know what problem this is intended to fix before
> we try to decide in which cases it's needed. Otherwise, whether we add
> it everywhere or remove it everywhere, we'll only know that it's
> consistent, not that it's correct.
The archeology reveals that these calls where originally added to
canonicalize the data_directory and config_file settings (7b0f060d54),
but that was then moved out of guc.c to be done early during postmaster
startup (337ffcddba). The remaining calls of check_canonical_path() in
guc.c appear to be leftovers from a previous regime.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Andy Fan | 2020-06-02 09:04:50 | Re: Hybrid Hash/Nested Loop joins and caching results from subplans |
Previous Message | Peter Eisentraut | 2020-06-02 08:57:40 | Re: OpenSSL 3.0.0 compatibility |