From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
Cc: Andres Freund <andres@anarazel.de>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: Teach pg_upgrade test to honor NO_TEMP_INSTALL
Date: Tue, 21 May 2019 15:09:59 -0400
Message-ID: <13157.1558465799@sss.pgh.pa.us> (raw)
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>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, andrew.dunstan@2ndquadrant.com, andres@anarazel.de
Subject: Re: Teach pg_upgrade test to honor NO_TEMP_INSTALL
In-Reply-To: <13157.1558465799@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox