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

Tom Lane wrote:

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