Re: Teach pg_upgrade test to honor NO_TEMP_INSTALL

From: Andres Freund <andres(at)anarazel(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Teach pg_upgrade test to honor NO_TEMP_INSTALL
Date: 2019-05-22 18:42:54
Message-ID: 20190522184254.vi5w4icue7vu4km5@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2019-05-22 14:27:51 -0400, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)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.

Oh, yes, that's what I meant.

> > 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.

Ok, will do.

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2019-05-22 18:48:19 Re: pg_dump throwing "column number -1 is out of range 0..36" on HEAD
Previous Message Tom Lane 2019-05-22 18:42:31 Re: Why could GEQO produce plans with lower costs than the standard_join_search?