Re: Teach pg_upgrade test to honor NO_TEMP_INSTALL

Hi,

On 2019-05-22 14:06:47 -0400, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
> > Seems what we need to fix the immediate issue is to ressurect:
>
> > # We need to make it use psql from our temporary installation,
> > # because otherwise the installcheck run below would try to
> > # use psql from the proper installation directory, which might
> > # be outdated or missing. But don't override anything else that's
> > # already in EXTRA_REGRESS_OPTS.
> > EXTRA_REGRESS_OPTS="$EXTRA_REGRESS_OPTS --bindir='$bindir'"
> > export EXTRA_REGRESS_OPTS
>
> > and put that into global scope.
>
> 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?

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):

On 11:

$ make -j16 -s uninstall
$ make -j16 -s temp-install
$ make -j16 -s -C src/bin/pg_upgrade/ check NO_TEMP_INSTALL=1
...
../../../src/test/regress/pg_regress --inputdir=/home/andres/src/postgresql-11/src/test/regress --bindir='/home/andres/build/postgres/11-assert//install/bin' --port=60851 --dlpath=. --max-concurrent-tests=20 --port=60851 --schedule=/home/andres/src/postgresql-11/src/test/regress/serial_schedule
(using postmaster on /tmp/pg_upgrade_check-uEwhDs, port 60851)
============== dropping database "regression" ==============
sh: 1: /home/andres/build/postgres/11-assert//install/bin/psql: not found

$ make -j16 -s install
$ make -j16 -s -C src/bin/pg_upgrade/ check NO_TEMP_INSTALL=1 && echo success
...
success

As you can see it uses pg_regress etc from the temp installation, but
psql from the full installation.

> (IOW, keep an eye on the cross-version-upgrade tests while
> you mess with this...)

I will. If you refer to the buildfarm ones: As far as I can tell they
don't use test.sh at all. Which makes sense, as we need cleanup steps
inbetween the regression run and pg_upgrade, and test.sh doesn't allow
for that.

https://github.com/PGBuildFarm/client-code/blob/master/PGBuild/Modules/TestUpgradeXversion.pm

Greetings,

Andres Freund