On mån, 2011-09-05 at 23:42 +0300, Peter Eisentraut wrote:
> On lör, 2011-09-03 at 19:58 -0400, Tom Lane wrote:
> > Anyway, after giving up on that I went back to plan A, namely install
> > regress.so and friends into $libdir. That turns out to be really quite
> > straightforward, though I had to hack pg_regress.c a bit to get its idea
> > of $libdir to match up exactly with the way the backend sees it.
> > (The only reason this matters is that there's one error report in the
> > regression tests where the full expansion of $libdir is reported.
> > Maybe we should just drop that one test case instead of maintaining
> > the infrastructure for replacing @libdir@ in pg_regress.c.)
> >
> > Attached is a draft patch for HEAD. It passes "make check" and "make
> > installcheck" on Unix, but I've not touched the MSVC scripts.
> > Comments?
>
> I'll try to integrate this with my pg_upgrade test runner to see if it
> gets the job done.
I found a simpler way to get this working. Just hack up the catalogs
for the new path directly. So I can now run this test suite against
older versions as well, like this:
contrib/pg_upgrade$ make installcheck oldsrc=somewhere oldbindir=elsewhere
The status is:
master -> master works.
9.1 -> master works.
9.0 -> master kind of works. The upgrade succeeds, but the dump has
differences because the languages are now dumped as extension commands.
It's easy to inspect manually, but won't work for any kind of automated
test runs.
8.4 -> master upgrade fails like this:
Restoring user relation files
Mismatch of relation names in database "regression": old name "pg_toast.pg_toast_27437", new name
"pg_toast.pg_toast_27309"
Failure, exiting
This has been 100% reproducible for me.
8.3 -> master upgrade doesn't work at all, because the regression test
database contains columns of type "name" and pg_upgrade won't upgrade
those from this version.
