Re: Teach pg_upgrade test to honor NO_TEMP_INSTALL

From: Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Teach pg_upgrade test to honor NO_TEMP_INSTALL
Date: 2019-05-21 18:48:27
Message-ID: aaee2cc8-d722-990c-b848-413ba9913703@2ndQuadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On 5/20/19 9:58 PM, Andres Freund wrote:
> Hi Andrew,
>
> On 2019-03-30 16:42:16 -0400, Andrew Dunstan wrote:
>> On some machines (*cough* Mingw *cough*) installs are very slow. We've
>> ameliorated this by allowing temp installs to be reused, but the
>> pg_upgrade Makefile never got the message. Here's a patch that does
>> that. I'd like to backpatch it, at least to 9.5 where we switched the
>> pg_upgrade location. The risk seems appropriately low and it only
>> affects our test regime.
> I'm confused as to why this was done as a purely optional path, rather
> than just ripping out the pg_upgrade specific install?
>
> See also discussion around https://www.postgresql.org/message-id/21766.1558397960%40sss.pgh.pa.us
>

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.

Note that the buildfarm doesn't run "make check-world" for reasons I
have explained in the past. NO_TEMP_INSTALL is particularly valuable in
saving time when running the TAP tests, especially on Mingw.

cheers

andrew

--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2019-05-21 19:06:43 Re: Remove useless associativity/precedence from parsers
Previous Message Tom Lane 2019-05-21 18:33:50 Re: New EXPLAIN option: ALL