Re: multi-install PostgresNode fails with older postgres versions

> On Apr 7, 2021, at 12:13 PM, Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
> 
> 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 was commenting on the design to have the PostgresNode derived subclass hard-coded to return "10" as the version:

    sub version { return 10 }


It's hard to think about how this other system works when you have lots of separate micro releases all compiled and used as the basis of the $node's, since this other system does not support that at all.  So maybe it can be done properly, but I don't want to have different microversions of 10 and then find that $a->version eq $b->version when $a is 10.1 and $b is 10.2.

>> I don't think it works to have a class per micro release.
> 
> I don't understand why you would do that.

If you need a "version" subroutine per derived class, then the only way to solve the problem is to have a profusion of derived classes.  It would make more sense to me if the version method worked the way I implemented it, where it just returns the version obtained from pg_config


—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company