Horton

Re: multi-install PostgresNode fails with older postgres versions

Alvaro Herrera <alvherre@alvh.no-ip.org>

View thread View on postgr.es
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Mark Dilger <mark.dilger@enterprisedb.com>
Cc: Jehan-Guillaume de Rorthais <jgdr@dalibo.com>, Andrew Dunstan <andrew@dunslane.net>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2021-04-07T20:28:50Z
Lists: pgsql-hackers 
On 2021-Apr-07, Mark Dilger wrote:

> I was commenting on the design to have the PostgresNode derived
> subclass hard-coded to return "10" as the version:
> 
>     sub version { return 10 }

That seems a minor bug rather than a showstopper design deficiency.
I agree that hardcoding the version in the source code is not very
usable; it should store the version number when it runs pg_config
--version in an instance variable that can be returned.

-- 
Álvaro Herrera                            39°49'30"S 73°17'W
Al principio era UNIX, y UNIX habló y dijo: "Hello world\n".
No dijo "Hello New Jersey\n", ni "Hello USA\n".

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.