Re: [HACKERS] New regression driver

wieck(at)debis(dot)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