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

Tom Lane wrote:

> I like the tcl/expect idea a lot.  We'd have to upgrade our tcl
> interface to support asynchronous queries (ie, send query then do other
> stuff until answer arrives); AFAIR it can't handle that now.  But that'd
> be well worth doing anyway...

O.K.

    The  multi session test tool, written in Tcl, is ready. Where
    should it go and how should it be named? I think it  wouldn't
    be a bad idea to have it in a place where it can be used from
    any location, instead of putting it into the regression  dir.
    Maybe install it into bin?

    Just to show a little:

    # ----
    # Multi session test suite
    # ----

    # ----
    # Session 1 starts a transaction and deletes all rows from t1
    # ----
    / connect A
    begin;
    select * from t1;
    delete from t1;
    / wait A

    # ----
    # Session 2 tries to select all from t1 for update - should block
    # ----
    / connect B
    begin;
    select * from t1 for update of t1;
    commit;
    / wait B

    # ----
    # Now session 1 rolls back ...
    # ----
    / use A
    rollback;
    / wait A

    # ----
    # ... what must release session 2
    # ----
    / wait B

    / close A
    / close B

    The above input produces this output:

    # ----
    # Multi session test suite
    # ----
    # ----
    # Session 1 starts a transaction and deletes all rows from t1
    # ----
    (A) QUERY: begin;
    (A) QUERY: select * from t1;
    (A) a1|b1|c1
    (A) --+--+-----
    (A)  2| 2|key 2
    (A)  3| 3|key 3
    (A)  8| 8|key 7
    (A) (3 rows)
    (A)
    (A) QUERY: delete from t1;
    # ----
    # Session 2 tries to select all from t1 for update - should block
    # ----
    (B) QUERY: begin;
    (B) QUERY: select * from t1 for update of t1;
    *** Session of connection B seems locked
    # ----
    # Now session 1 rolls back ...
    # ----
    (A) QUERY: rollback;
    # ----
    # ... what must release session 2
    # ----
    (B) a1|b1|c1
    (B) --+--+-----
    (B)  2| 2|key 2
    (B)  3| 3|key 3
    (B)  8| 8|key 7
    (B) (3 rows)
    (B)
    (B) QUERY: commit;

    The default time for the "wait" command is 5 seconds, but can
    be specified explicitly as "wait A 10". Session names can  of
    course be longer than one character.

    The  script stopped at session B's SELECT ... FOR UPDATE, and
    correctly continued with the *** message 5 seconds later.  As
    you  might have noticed, it doesn't matter that the COMMIT of
    session 2 was  placed  directly  after  the  SELECT.  If  the
    session hangs, all queries are internally buffered.


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