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