New regression driver - Mailing list pgsql-hackers

I't committed.

    There  is  a  new shell script run_check.sh in the regression
    test directory.  It  is  driven  by  the  conficuration  file
    ./sql/run_check.tests and runs most of our tests parallel. It
    is invoked with the new GNUmakefile target 'runcheck'.


    The regress.sh is using the new tests file too by  extracting
    the  tests to run via awk, so ./sql/tests is obsolete now and
    subject to be removed soon.

Bruce Momjian wrote:

> 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?

    Thus, it does a complete  independant  database  installation
    below  the regression test, starting it's own postmaster (and
    terminating it at the end, of course). The entire test  suite
    can be run without even shutting down the currently installed
    database.

    So a

       ...src > ./configure
       ...src > make
       ...src > cd test/regression
       ...src/test/regression > make clean all runcheck

    sequence will compile and temporarily install the  new  build
    under the regression path, and then run all the tests against
    it.

    I think if my new test driver has settled, we  should  change
    the GNUmakefile to just print some messages if 'make runtest'
    is typed.  The current runtest target should  IMHO  still  be
    availabe   under   another   name,  to  test  the  real  life
    installation created by 'make install'.

    Alternatively (IMHO better) some  parameter  to  run_check.sh
    could   tell   if   it  should  create  it's  own,  temporary
    installation, or if it  should  use  the  existing  installed
    database system and the already running postmaster.

Tom Lane wrote:

> In other words, you've already exposed a bug!  Right on!

    Absolutely  right  and  I've commented out that code for now.
    It is in utils/cache/catcache.c line 996.  The  comments  say
    that  the  code  should  prevent  the  backend  from entering
    infinite recursion while loading new cache entries.  But  the
    flag  used  for it seems to live in shared memory, thus it is
    affected by other backends too. If the flag is  true  doesn't
    tell if a backend set it itself, or if another one did. If we
    really need this check, it must  be  implemented  in  another
    way.

    Another bug I discoverd is that Vadims WAL code allways looks
    for the pg_control file in the PGDATA or compiled in  default
    directory,  ignoring  the  -D  switch. Haven't fixed it up to
    now, but run_check.sh  uses  PGDATA,  so  it's  safe  at  the
    moment.

    I  ran  the  old  regress.sh  using  the default installation
    parallel to the run_check.sh using it's own installation  and
    postmaster.


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) #