Re: multi-install PostgresNode fails with older postgres versions
Jehan-Guillaume de Rorthais <jgdr@dalibo.com>
From: Jehan-Guillaume de Rorthais <jgdr@dalibo.com>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Mark Dilger <mark.dilger@enterprisedb.com>, Andrew Dunstan
<andrew@dunslane.net>, PostgreSQL-development
<pgsql-hackers@postgresql.org>
Date: 2021-04-07T18:07:41Z
Lists: pgsql-hackers
On Wed, 7 Apr 2021 13:36:31 -0400
Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
> On 2021-Apr-07, Jehan-Guillaume de Rorthais 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.
My version is currently calling pg_config without any knowledge about its
absolute path.
Mark's patch is able to take an explicit binary path:
my $a = PostgresNode->get_new_node('a', install_path => '/my/install/8.4');
> In order to avoid having an ever-growing plethora of 100-byte .pm files,
> we can put the version-specific classes in the same PostgresNode.pm
> file, at the bottom, "class PostgresNode96; use parent PostgresNode10;"
> followed by the routines that are overridden for each version.
Sure.
> > Let me know if it worth that I work on an official patch.
>
> Let's give it a try ...
OK
Regards,
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