Re: [HACKERS] psql & regress tests - Mailing list pgsql-hackers

Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
>
> > Any modifications to shared pg_ tables would be a problem.  Also, pg_log
> > and pg_variable locking is not happening in there either, is it?
>
> Good point --- it wouldn't be just that database, but the whole
> installation (data directory) that would have to be unused.  You really
> wouldn't dare even have a postmaster running, at least not in the same
> data directory.  But that could be made safe by using a nonstandard
> location for the data directory for regression.
>
> However, this is all beside the main point: we want the regress tests
> to run in an environment as close as possible to the way Postgres is
> normally used.  The more we hack up a special regress-test environment,
> the less the tests reflect reality.

    My new script actually does a

        make POSTGRESDIR=somewhere_else install
        PATH="somewhere_else/bin:$PATH"

    Then  it  initializes  a  database  below  there and starts a
    postmaster with the resulting data  directory,  listening  on
    port 65432.

    So  I  think  it's  very  close  to  a real live setup, while
    another "production" running installation isn't  affected  at
    all.

> Aside from the cross-backend synchronization issue, I forgot to point
> out a really obvious benefit: doing it the current way allows the regress
> tests to help check the backend's frontend communication code, and
> libpq, and psql itself.  We'd need some other way of testing all that
> code if we switched to a standalone-backend regression test set.
>
> What I *would* like to see is more support for running regress tests on
> a not-yet-installed build, so people can test a fresh build before they
> blow away their working installation.  This requires doing an initdb
> into a temporary directory, starting a postmaster therein (using a
> nonstandard port number), and running the tests there.  This is doable
> by hand, of course, but it's tedious and error-prone even for an expert;
> I think it's out of the question for a novice installer.  We ought to
> offer a canned script to do it that way.

    Right, right, right - I'm on it.

    The  ugly  detail,  I'm currently running into, is that there
    already seems to be a concurrency problem I  discovered  with
    my  testing.  Occationally I get this into the postmaster log
    for parallel executing tests:

ERROR:  Bad boolean external representation 'XXX'
FATAL 1:  SearchSysCache: recursive use of cache 10
FATAL 2:  elog: error in postmaster or backend startup, giving up!
pq_flush: send() failed: Broken pipe
Server process (pid 9791) exited with status 512 at Fri Nov 19 03:17:09 1999
Terminating any active server processes...

    It happens during the first parallel group of 11  tests.  Not
    allways, so it's timing critical. Outch.


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#========================================= wieck@debis.com (Jan Wieck) #