Re: multi-install PostgresNode fails with older postgres versions
Alvaro Herrera <alvherre@alvh.no-ip.org>
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-07T19:13:14Z
Lists: pgsql-hackers
On 2021-Apr-07, Mark Dilger wrote: > It's not sufficient to think about postgres versions as "10", "11", > etc. You have to be able to spin up nodes of any build, like "9.0.7". > There are specific versions of postgres with specific bugs that cause > specific problems, and later versions of postgres on that same > development branch have been patched. If you only ever spin up the > latest version, you can't reproduce the problems and test how they > impact cross version compatibility. I don't get it. Surely if you need 10.0.7 you just compile that version and give its path as install path? You can have two 1.0.x as long as install them separately, right? > I don't think it works to have a class per micro release. I don't understand why you would do that. -- Álvaro Herrera 39°49'30"S 73°17'W "Crear es tan difícil como ser libre" (Elsa Triolet)
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