Re: multi-install PostgresNode

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: multi-install PostgresNode
Date: 2020-12-19 16:19:07
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On 12/17/20 7:55 PM, Michael Paquier wrote:
> On Thu, Dec 17, 2020 at 04:37:54PM -0500, Andrew Dunstan wrote:
>> The proposed module would look something like this:
>> [...]
>> use parent PostgresNode;
>> sub get_new_node
>> {
>>     my $installpath= shift;
>>     my $node = PostgresNode::get_new_node(@_);
>>     bless $node; # re-bless into current class
>>     $node->{_installpath} = $installpath;
>>     return $node;
>> }
> Passing down the installpath as argument and saving it within a
> PostgresNode or child class looks like the correct way of doing things
> to me. This would require an extra routine to be able to get the
> install path from a node as _installpath would remain internal to the
> module file, right? Shouldn't it be something that ought to be
> directly part of PostgresNode actually, where we could enforce the lib
> and bin paths to the output of pg_config if an _installpath is not
> provided by the caller? In short, I am not sure that we need an extra
> module here.
>> and then  for each class method in we'd have an override
>> something like:
>> sub foo
>> {
>>     my $node=shift;
>>     my $inst = $node->{_installpath};
>>     local %ENV = %ENV;
>>     $ENV{PATH} = "$inst/bin:$ENV{PATH}";
>>     $ENV{LD_LIBRARY_PATH} = "$inst/lib:$ENV{LD_LIBRARY_PATH}";
>>     $node->SUPER::foo(@_);
>> }
>> There might be more elegant ways of doing this, but that's what I came
>> up with.
> As long as it does not become necessary to pass down _installpath to
> all indidivual binary calls we have in PostgresNode or the extra
> module, this gets a +1 from me. So, if I am getting that right, the
> key point is the use of local %ENV here to make sure that PATH and
> LD_LIBRARY_PATH are only enforced when it comes to calls within
>, right? That's an elegant solution. This is
> something I have wanted for a long time for pg_upgrade to be able to
> get rid of its
>> My main question is: do we want something like this in the core code
>> (presumably in src/test/perl), or is it not of sufficiently general
>> interest? If it's wanted I'll submit a patch, probably for the March CF,
>> but January if I manage to get my running shoes on. If not, I'll put it
>> in the buildfarm code, but then any TAP tests that want it will likewise
>> need to live there.
> This facility gives us the possibility to clean up the test code of
> pg_upgrade and move it to a TAP test, so I'd say that it is worth
> having in the core code in the long-term.

This turns out to be remarkably short, with the use of a little eval magic.

Give the attached, this test program works just fine:

use PostgresNodePath;
my $node = get_new_node('/home/andrew/pgl/inst.12.5711','blurfl');
print $node->info;
print $node->connstr(),"\n";



Andrew Dunstan

Attachment Content-Type Size application/x-perl 2.9 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2020-12-19 16:58:37 Re: Proposed patch for key managment
Previous Message Konstantin Knizhnik 2020-12-19 12:50:30 Re: Double partition lock in bufmgr