Peter Eisentraut <pete...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
