From: | Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: multi-install PostgresNode fails with older postgres versions |
Date: | 2021-03-31 00:59:08 |
Message-ID: | A8DE97E5-3F50-472A-B8AA-153EE145F8FD@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> On Mar 30, 2021, at 5:52 PM, Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>
> On Tue, Mar 30, 2021 at 08:44:26PM -0400, Andrew Dunstan wrote:
>> Yeah, it should be validated. All things considered I think just calling
>> 'pg_config --version' is probably the simplest validation, and likely to
>> be sufficient.
>>
>> I'll try to come up with something tomorrow.
>
> There is already TestLib::check_pg_config(). Shouldn't you leverage
> that with PG_VERSION_NUM or equivalent?
Only if you change that function. It doesn't currently do anything special to run the *right* pg_config.
The patch I sent takes the view that once the install_path has been sanity checked and the *right* pg_config executed, relying on the environment's path variables thereafter is safe. But that means the initial pg_config execution is unique in not being able to rely on the path. There really isn't enough motivation for changing TestLib, I don't think, because subsequent calls to pg_config don't need to be paranoid, just the first call.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2021-03-31 01:01:45 | Re: Refactor SSL test framework to support multiple TLS libraries |
Previous Message | Michael Paquier | 2021-03-31 00:52:35 | Re: multi-install PostgresNode fails with older postgres versions |