Re: multi-install PostgresNode fails with older postgres versions

From: Jehan-Guillaume de Rorthais <jgdr(at)dalibo(dot)com>
To: Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com>
Cc: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: multi-install PostgresNode fails with older postgres versions
Date: 2021-04-07 18:15:40
Message-ID: 20210407201540.0ab39caf@firost
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On Wed, 7 Apr 2021 10:50:26 -0700
Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com> wrote:

> > On Apr 7, 2021, at 10:36 AM, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> wrote:
> >
> >> Yes, it would be much saner to make PostgresNode the factory class. Plus,
> >> some more logic could be injected there to either auto-detect the version
> >> (current behavior) or eg. use a given path to the binaries as Mark did in
> >> its patch.
> >
> > I'm not sure what you mean about auto-detecting the version -- I assume
> > we would auto-detect the version by calling pg_config from the
> > configured path and parsing the binary, which is what Mark's patch is
> > supposed to do already. So I don't see what the distinction between
> > those two things is.
> >
> > In order to avoid having an ever-growing plethora of 100-byte .pm files,
> > we can put the version-specific classes in the same
> > file, at the bottom, "class PostgresNode96; use parent PostgresNode10;"
> > followed by the routines that are overridden for each version.
> 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 think it works to have a class per micro release. So you'd have a
> PostgresNode of type "10" or such, but how does that help? If you have ten
> different versions of "10" in your test, they all look the same?

As PostgresNode factory already checked pg_config version, it can give it as
argument to the specific class constructor. We can then have eg.
major_version() and version() to return the major version and full versions.


In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jehan-Guillaume de Rorthais 2021-04-07 18:35:40 Re: multi-install PostgresNode fails with older postgres versions
Previous Message Bruce Momjian 2021-04-07 18:12:11 Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view?