From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Matt Miller <mattm(at)epx(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Testing of MVCC |
Date: | 2005-08-15 22:01:20 |
Message-ID: | 17026.1124143280@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
Matt Miller <mattm(at)epx(dot)com> writes:
> The attached patch allows src/test/regress/pg_regress.sh to recognize
> lines that begin with "curr_test:" in the schedule file. Tests named on
> such a line are run concurrently across multiple connections.
This doesn't seem like any advance over the existing parallel-test
facility. Synchronizing the test starts slightly more closely
isn't really going to buy anything: you still can't control or even
predict relative progress.
> Maybe the simplest solution is to force test writers to generate output
> that does not depend on the relative progress of any concurrent tests.
Well, that's exactly the situation we have now, and it's not really
adequate.
What we really need is a test program that can issue a command on one
connection (perhaps waiting for it to finish, perhaps not) and then
issue other commands on other connections, all according to a script.
I am unsure that the existing pg_regress infrastructure is the right
place to start from. Perhaps we should look at Expect or something
similar.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Aly Dharshi | 2005-08-15 22:05:12 | Re: Postgresql Books: Which one ? |
Previous Message | Thomas F. O'Connell | 2005-08-15 21:54:31 | Re: How to implement table caching |
From | Date | Subject | |
---|---|---|---|
Next Message | Matt Miller | 2005-08-15 22:37:06 | Re: Testing of MVCC |
Previous Message | Matt Miller | 2005-08-15 21:41:13 | Re: Testing of MVCC |