Tom Lane wrote:
> Admittedly, running a bunch of tests serially isn't a strong stress test
> of cross-backend behavior, but it's not as content-free a check as you
> might think. On my machine, at least, the old backend is still around
> doing shutdown for the first half-second or so while the next one is
> running.
>
> What I'd really like to see is some deliberate parallelism in some of
> the regress tests...
It's amusing how often we two have the same wishes or ideas.
The run_check.sh script, I'm actually hacking on, would be a
replacement for the regress.sh, started off from the 'make
check'. And from the first try I added syntax to the
sql/tests file to run either groups of tests parallel
intermixed with single tests sequentially.
The new syntax will look like this:
parallel group1
test boolean
test char
test name
endparallel
test varchar
test text
test strings
parallel group2
test int2
test int4
test int8
endparallel
.
.
.
The above will run boolean, char and name parallel. After all
three terminated, it will check their output and continue to
run varchar, text and strings sequentially, followed by the
next parallel group.
To test real concurrency we might need to split up some or
create new tests, where the same tables are accessed
concurrently. But that wouldn't be hard to do I think.
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) #
