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
-
Teach PostgresVersion all the ways to mark non-release code
- aa271209f6d9 14.0 landed
-
Make PostgresNode version aware
- 4c4eaf3d1920 14.0 landed
-
Avoid unfortunate IPC::Run path caching in PostgresNode
- 95c3a1956ec9 14.0 landed
-
Change pg_ctl to detect server-ready by watching status in postmaster.pid.
- f13ea95f9e47 10.0 cited