Re: [HACKERS] New regression driver - Mailing list pgsql-hackers

wieck@debis.com (Jan Wieck) writes:
>     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'.

This is way cool.  I had to fix a couple of silly little portability
problems,  but I like 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.

We should leave the old driver available, so that if an unexpected
problem arises one can easily check to see if it's being triggered by
concurrent execution or not.  Or, run_check could have a parameter to
force serialized execution, if you would rather have just one script.
In that case we could toss the old runtest and rename run_check to
runtest.  (If we do keep both scripts, can we pick more helpful names
than "runtest" and "run_check"?  The difference is not immediately
obvious...)

I agree that run_check needs to be able to test a normal installation
as well as a temporary one.

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

I will look at this.  I don't think that the catcaches live in
shared memory, so the problem is probably not what you suggest.
The fact that the behavior is different under load may point to a
real problem, not just an insufficiently clever debugging check.

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

They both give the same results on my platform, too.
        regards, tom lane