New regression driver

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(at)debis(dot)com (Jan Wieck) #