Subject: Re: Rewriting the test of pg_upgrade as a TAP test - take two
To: Michael Paquier <michael@paquier.xyz>,
 Craig Ringer <craig@2ndquadrant.com>
References: <20180126080026.GI17847@paquier.xyz>
 <7d040dbb-33f3-edb7-b13d-0f4ab607af46@2ndquadrant.com>
 <CAA8=A79KwJ4Yt3C9LAMt9-i+N=jDP2Z+NoE0qh069BetX0kmCw@mail.gmail.com>
 <CAA8=A7-xR98DkqdoTAui3i4Y17xJPrMrxYGr9KDh0Hs0qVYjMg@mail.gmail.com>
 <08724398-ce66-9236-18fc-b7f22a15c017@2ndquadrant.com>
 <18045.1520370764@sss.pgh.pa.us>
 <0b59536a-2d31-7573-6505-1860d00618bd@pgmasters.net>
 <20180322013957.GD2490@paquier.xyz>
 <CAMsr+YE2H+BULrLr+8OJKxKVS=d7PuUqHPWRESs_ncaN=Was3w@mail.gmail.com>
 <20180322014957.GF2490@paquier.xyz>
Cc: David Steele <david@pgmasters.net>,
 Andrew Dunstan <andrew.dunstan@2ndquadrant.com>, Tom Lane
 <tgl@sss.pgh.pa.us>, Michael Paquier <michael.paquier@gmail.com>,
 Postgres hackers <pgsql-hackers@postgresql.org>
From: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Organization: 2ndQuadrant
Message-ID: <c4c618c2-8ab4-df89-0f08-4f56cb4ac27c@2ndquadrant.com>
Date: Mon, 2 Apr 2018 10:35:09 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0)
 Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <20180322014957.GF2490@paquier.xyz>
Content-Type: text/plain; charset=windows-1252
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 3/21/18 21:49, Michael Paquier wrote:
> On Thu, Mar 22, 2018 at 09:42:35AM +0800, Craig Ringer wrote:
>> I'm super excited by the idea of multi-version support in TAP, if that's
>> what you mean.
>>
>> Why? Because I use TAP heavily in extensions. Especially replication
>> extensions. Which like to talk across multiple versions. I currently need
>> external test frameworks and some hideous hacks to do this.
> 
> Okay, in front of such enthusiasm we could keep at least the refactoring
> part of PostgresNode.pm :)

I took a quick look at that part.  It appears to be quite invasive, more
than I would have hoped.  Basically, it imposes that from now on all
program invocations must observe the bindir setting, which someone is
surely going to forget.  The pg_upgrade tests aren't going to exercise
all possible paths where programs are called, so this is going to lead
to omissions and inconsistencies -- which will then possibly only be
found much later by the extensions that Craig was talking about.  I'd
like to see this more isolated, maybe via a path change, or something
inside system_or_bail or something less invasive and more maintainable.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services