Re: pg_upgrade automatic testing - Mailing list pgsql-hackers

From Tom Lane
Subject Re: pg_upgrade automatic testing
Date
Msg-id 26374.1314735936@sss.pgh.pa.us
Whole thread Raw
In response to Re: pg_upgrade automatic testing  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: pg_upgrade automatic testing
Re: pg_upgrade automatic testing
Re: pg_upgrade automatic testing
List pgsql-hackers
Peter Eisentraut <peter_e@gmx.net> writes:
> +# contrib/pg_upgrade/test.sh
> +#
> +# Test driver for pg_upgrade.  Initializes a new database cluster,
> +# runs the regression tests (to put in some data), runs pg_dumpall,
> +# runs pg_upgrade, runs pg_dumpall again, compares the dumps.

Hm .. my experience is that that doesn't work at all, because the
regression tests set up assorted C functions whose implementations are
in pg_regress.so, and it creates them with absolute path references
to pg_regress.so.  When you try to load that into another installation
that's a different version of PG, it quite properly fails.  So I think
that as given, this script is only useful for testing pg_upgrade of
$currentversion to $currentversion.  Which is surely better than no test
at all, but it would not for example have caught the 8.3 incompatibility
that was just reported.

How can we improve things here?  I've toyed with the idea of installing
pg_regress.so so that we can refer to it relative to $libdir, but that
might be a bit invasive, especially if we were to try to back-patch it
as far as 8.3.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: spinlocks on HP-UX
Next
From: Magnus Hagander
Date:
Subject: Re: pg_upgrade automatic testing