Re: multi-install PostgresNode fails with older postgres versions - Mailing list pgsql-hackers

From Mark Dilger
Subject Re: multi-install PostgresNode fails with older postgres versions
Date
Msg-id 3B4AB103-CA71-48C9-8D12-8834E9C5B36F@enterprisedb.com
Whole thread Raw
In response to Re: multi-install PostgresNode fails with older postgres versions  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Responses Re: multi-install PostgresNode fails with older postgres versions  (Mark Dilger <mark.dilger@enterprisedb.com>)
List pgsql-hackers

> On Mar 30, 2021, at 3:22 PM, Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
>
>> One of the things I noticed while playing with this new toy (thanks,
>> Andrew!) is that if you pass a completely insane install_path, you
>> don't get any errors.  In fact, you get executables and libraries from
>> whatever PATH="/no/such/postgres:$PATH" gets you, probably the
>> executables and libraries of your latest development branch.  By
>> forcing get_new_node to call the pg_config of the path you pass in,
>> you'd fix that problem.  I didn't do that, mind you, but you could.  I
>> just executed pg_config, which means you'll still get the wrong
>> version owing to the PATH confusion.
>
> Hmm, I think it should complain if you give it a path that doesn't
> actually contain a valid installation.

I felt the same way, but wondered if Andrew had set path variables without sanity checking the install_path argument
forsome specific reason, and didn't want to break something he did intentionally.  If that wasn't intentional, then
thereare two open bugs/infelicities against master: 

1) PostgresNode::init() doesn't work for older server versions

2) PostgresNode::get_new_node() doesn't reject invalid paths, resulting in confusion about which binaries subsequently
getexecuted 

I think this next version of the patch addresses both issues.  The first issue was already fixed in the previous patch.
The second issue is also now fixed by forcing the usage of the install_path qualified pg_config executable, rather than
usingwhatever pg_config happens to be found in the path. 

There is an existing issue that if you configure with --bindir=$SOMEWHERE_UNEXPECTED, PostgresNode won't work.  It
inserts${install_path}/bin and ${install_path}/lib into the environment without regard for whether "bin" and "lib" are
correct. That's a pre-existing limitation, and I'm not complaining, but just commenting that I didn't do anything to
fixit. 

Keeping the WIP marking on the patch until we hear Andrew's opinion on all this.



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




Attachment

pgsql-hackers by date:

Previous
From: Jaime Casanova
Date:
Subject: cursor already in use, UPDATE RETURNING bug?
Next
From: Thomas Munro
Date:
Subject: Re: [PATCH v3 1/1] Fix detection of preadv/pwritev support for OSX.