Re: Teach pg_upgrade test to honor NO_TEMP_INSTALL - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Teach pg_upgrade test to honor NO_TEMP_INSTALL
Date
Msg-id 7965.1558549671@sss.pgh.pa.us
Whole thread Raw
In response to Re: Teach pg_upgrade test to honor NO_TEMP_INSTALL  (Andres Freund <andres@anarazel.de>)
Responses Re: Teach pg_upgrade test to honor NO_TEMP_INSTALL  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
> On 2019-05-22 14:06:47 -0400, Tom Lane wrote:
>> Not sure about that last bit.  pg_upgrade has the issue of possibly
>> wanting to deal with 2 installations, unlike the rest of the tree,
>> so I'm not sure that fixing its problem means there's something we
>> need to change everywhere else.

> I'm not quite following? We need to move it into global scope to fix the
> issue at hand (namely that we currently need to make install first, just
> to get psql).  And at which scope could it be in master, other than
> global?

Maybe I misunderstood you --- I thought you were talking about something
like defining EXTRA_REGRESS_OPTS in Makefile.global.  If you mean
running this unconditionally within test.sh, I've got no objection
to that.

> I do think we will have to move it to the global scope in the back
> branches too, because NO_TEMP_INSTALL does indeed fail without a global
> install first (rather than using the temp install, as intended):

Agreed, we should fix it in all branches, because it seems like it's
probably testing the wrong thing, ie using the later branch's psql
to run the earlier branch's regression tests.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: pg_dump throwing "column number -1 is out of range 0..36" on HEAD
Next
From: Donald Dong
Date:
Subject: Re: Why could GEQO produce plans with lower costs than thestandard_join_search?