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: Andrew Dunstan <andrew(at)dunslane(dot)net>, Bruce Momjian <bruce(at)momjian(dot)us>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_upgrade automatic testing
Date: 2011-09-03 23:58:12
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> On fre, 2011-09-02 at 19:49 -0400, Tom Lane wrote:
>> The only one that's problematic is; contrib modules are
>> already installed in $libdir. I still think that installing
>> 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 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.

regards, tom lane

Attachment Content-Type Size
no-absolute-libdir-in-tests.patch text/x-patch 21.6 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2011-09-04 00:51:13 Re: [COMMITTERS] pgsql: Remove "fmgr.h" include in cube contrib --- caused crash on a Ge
Previous Message Bruce Momjian 2011-09-03 23:18:47 Large C files