Re: multi-install PostgresNode fails with older postgres versions

Mark Dilger <mark.dilger@enterprisedb.com>

From: Mark Dilger <mark.dilger@enterprisedb.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: Andrew Dunstan <andrew@dunslane.net>, Alvaro Herrera <alvherre@alvh.no-ip.org>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2021-03-31T00:59:08Z
Lists: pgsql-hackers

> On Mar 30, 2021, at 5:52 PM, Michael Paquier <michael@paquier.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






Commits

  1. Teach PostgresVersion all the ways to mark non-release code

  2. Make PostgresNode version aware

  3. Avoid unfortunate IPC::Run path caching in PostgresNode

  4. Change pg_ctl to detect server-ready by watching status in postmaster.pid.