Re: multi-install PostgresNode fails with older postgres versions

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

In response to

Browse pgsql-hackers by date

  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