Re: pg_upgrade automatic testing

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_upgrade automatic testing
Date: 2011-08-30 20:25:36
Message-ID: 26374.1314735936@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Eisentraut <peter_e(at)gmx(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Magnus Hagander 2011-08-30 20:28:00 Re: pg_upgrade automatic testing
Previous Message Robert Haas 2011-08-30 20:23:48 Re: spinlocks on HP-UX