Re: pg_upgrade automatic testing
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Eisentraut <peter_e@gmx.net>
Cc: Andrew Dunstan <andrew@dunslane.net>, Bruce Momjian <bruce@momjian.us>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2011-09-03T23:58:12Z
Lists: pgsql-hackers
Attachments
- no-absolute-libdir-in-tests.patch (text/x-patch)
Peter Eisentraut <peter_e@gmx.net> writes: > On fre, 2011-09-02 at 19:49 -0400, Tom Lane wrote: >> The only one that's problematic is pg_regress.so; contrib modules are >> already installed in $libdir. I still think that installing >> pg_regress.so in $libdir may be the most reasonable solution, assuming >> that the delta involved isn't too great. Yeah, we would have to >> back-patch the changes into every release branch we want to test >> upgrading from, but how risky is that really? The *only* thing it >> affects is the regression tests. > Or maybe make use of dynamic_library_path. That seemed like a promising idea at first, but on reflection I thought probably it's not such a great idea. The problem is, where do you inject the setting? In a temp installation we could put it in postgresql.conf, but for "make installcheck" the only way that seems like it would work at all is to apply it as a database configuration (ALTER DATABASE SET), and that seems problematic. In particular, it would not work for testing pg_dump, since pg_dump doesn't copy those settings. (I know we've talked about making it do so, but we'd certainly not wish to back-patch such a change.) (BTW, this also strikes me as a counterexample for the recently proposed change to make pg_dumpall dump such settings at the end. If you've got datatypes or indexes that depend on a shared library that's found via "ALTER DATABASE SET dynamic_library_path", it will absolutely not work to restore the database contents before that setting is applied.) 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? regards, tom lane