From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
cc: Andres Freund <andres@anarazel.de>,
        PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: Teach pg_upgrade test to honor NO_TEMP_INSTALL
In-reply-to: <aaee2cc8-d722-990c-b848-413ba9913703@2ndQuadrant.com>
References: <5506b8fa-7dad-8483-053c-7ca7ef04f01a@2ndQuadrant.com>
 <20190521015840.cztw2qxthh7xuutk@alap3.anarazel.de>
 <aaee2cc8-d722-990c-b848-413ba9913703@2ndQuadrant.com>
Comments: In-reply-to Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
	message dated "Tue, 21 May 2019 14:48:27 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <13156.1558465799.1@sss.pgh.pa.us>
Date: Tue, 21 May 2019 15:09:59 -0400
Message-ID: <13157.1558465799@sss.pgh.pa.us>
Precedence: bulk

Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:
> On 5/20/19 9:58 PM, Andres Freund wrote:
>> I'm confused as to why this was done as a purely optional path, rather
>> than just ripping out the pg_upgrade specific install?

> By specifying NO_TEMP_INSTALL you are in effect certifying that there is
> already a suitable temp install available. But that might well not be
> the case. In fact, there have been several iterations of code to get the
> buildfarm client to check reasonable reliably that there is such an
> install before it chooses to use the flag.

Right.  Issuing "make check" in src/bin/pg_upgrade certainly shouldn't
skip making a new install.  But if we're recursing down from a top-level
check-world, we ought to be able to use the install it made.

			regards, tom lane