From: | Matt Miller <mattm(at)epx(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Testing of MVCC |
Date: | 2005-08-15 21:41:13 |
Message-ID: | 1124142074.3361.34.camel@dbamm01-linux |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
On Mon, 2005-08-08 at 16:59 -0400, Tom Lane wrote:
> Matt Miller <mattm(at)epx(dot)com> writes:
> > I want to write some regression tests that confirm the behavior of
> > multiple connections simultaneously going at the same tables/rows. Is
> > there something like this already, e.g. in src/test/regress?
>
> No. ... but surely we need one.
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. To make
use of this facility each test in the group must begin with the line:
select * from concurrency_test where key = '<test_name>' for update;
where <test_name> is replace by the name of that test. This will enable
pg_regress to start this test at the same time as the other tests in the
group.
Is this a reasonable starting point for a concurrent testing framework?
This does not address the issue of how to interpret the test output.
Maybe the simplest solution is to force test writers to generate output
that does not depend on the relative progress of any concurrent tests.
Or, maybe the "ignore:" directive in the schedule file could be employed
somehow.
Attachment | Content-Type | Size |
---|---|---|
curr_test.patch | text/x-patch | 4.7 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas F. O'Connell | 2005-08-15 21:54:31 | Re: How to implement table caching |
Previous Message | Andreas Seltenreich | 2005-08-15 21:30:32 | Re: Sorting by related tables |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2005-08-15 22:01:20 | Re: Testing of MVCC |
Previous Message | Tino Wildenhain | 2005-08-15 20:42:56 | Re: pl/Ruby, deprecating plPython and Core |