Re: multi-install PostgresNode fails with older postgres versions

Mark Dilger <mark.dilger@enterprisedb.com>

From: Mark Dilger <mark.dilger@enterprisedb.com>
To: Jehan-Guillaume de Rorthais <jgdr@dalibo.com>
Cc: Andrew Dunstan <andrew@dunslane.net>, Alvaro Herrera <alvherre@alvh.no-ip.org>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2021-04-19T18:17:11Z
Lists: pgsql-hackers

> On Apr 19, 2021, at 10:50 AM, Jehan-Guillaume de Rorthais <jgdr@dalibo.com> wrote:
> 
>> The community needs a single shared PostgresNode implementation that can be
>> used by scripts which reproduce bugs.
> 
> Which means it could be OK to have a PostgresNode implementation, leaving in
> core source-tree, which supports broader needs than the core ones (older
> versions and some more methods)? Did I understood correctly?

Yes, I believe it should be in core.

I don't know about "some more methods", as it depends which methods you are proposing.

> If this is correct, I suppose this effort could be committed early in v15 cycle?

I don't care to speculate on that yet.

> Does it deserve some effort to build some dedicated TAP tests for these
> modules? I already have a small patch for this waiting on my disk for some more
> tests and review...

I did that, too, in the 0002 version of my patch.  Perhaps we need to merge your work and mine.

—
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.