Thread

  1. Re: pg_upgrade automatic testing

    Tom Lane <tgl@sss.pgh.pa.us> — 2011-09-03T23:58:12Z

    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