Re: [HACKERS] Parallel regress tests (was Re: FOREIGN KEY andshift/reduce)

Tom Lane wrote:

> wieck(at)debis(dot)com (Jan Wieck) writes:
> > The multi session test tool, written in Tcl, is ready.
>
> Looks way cool.

Did I ever say that I love Tcl :-) ?

It took me less that 5 hours to create a full featured tool,
that already discovered another bug (not yet fixed) in the RI
procs, close to that Hiroshi reported (just do the violation
the other way round and it will be accepted).

I know, that there are similar powerful languages availabel
(perl for one). It's just that I looked for a good scripting
language some years ago and found Tcl (version 7.4 at that
time). Today it is such a magic tool for someone, familiar
with the C language, that I think it was one of the best
coices I ever made. Tcl was the first language I ever
embedded as a PL, and the difficulties reported (and yet
missing results) on approaches to embedd other languages tell
the entire story.

> > Where should it go and how should it be named?
>
> Why not throw it in as another src/bin/ subdirectory, or maybe put it
> in Peter's new "src/bin/scripts/" directory? No great ideas for
> a name here.

Exactly what I intended to do.

I prefer src/bin, since it isn't a shell script. I think that
"pgmultitest" (my internal development name) wouldn't be such
a bad decision.

> > The default time for the "wait" command is 5 seconds, but can
> > be specified explicitly as "wait A 10".
>
> It makes me uncomfortable that there are any explicit times at all.
> A developer might set up a test script with delays that seem ample
> on his hardware, yet will fail when someone tries to use the script
> on a much slower and/or heavily loaded system.
>
> Can we find a way to avoid needing explicit times in the scripts?
> If not, there should probably be a command-line switch that allows all
> the times to be scaled by some amount. (Ugly, but could be really
> handy.)

Once again, similar thoughts and feelings.

The third parameter should indeed be a value used internally
to ESTIMATE the real time require, to tell that the session
is blocked in a lock operation. And the estimation should be
based on some prior analyzed system performance.

Load peak's might still confuse the estimation. I don't have
any clue right now, how to estimate, but anyway, load peaks
lead to estimator confusions when it comes to estimate the
execution time of some operation.

I don't think, that a few (1-2) seconds of delay at an
expected lock would really hurt. Well, a test stressing the
locking mechanism (like the RI test I want to have), might
take a while, even if executed on high end hardware. But I
cannot imagine any other way, than using multiple sessions
and response timeouts, to detect from the outside that a
query ended in a blocking lock request.

Except we extend the entire FE/BE protocol with information,
telling "I'm blocked" / "I'm resuming" (plus adding
appropriate messages to psql), there is absolutely no way to
avoid the above timeouts. And we don't want to add regression
test requirements to the FE/BE protocol and psql - no? The
already discussed flushing feature is a requirement, but it
might be useful in other situations too and thus worth
anyway.

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