Re: Testing of MVCC
От
Matt Miller
Тема
Re: Testing of MVCC
Дата
Msg-id
1124142074.3361.34.camel@dbamm01-linux
Ответ на
Re: [GENERAL] Testing of MVCC (Matt Miller)
Список
Дерево обсуждения
Re: [GENERAL] Testing of MVCC Matt Miller <mattm@epx.com>
Re: Testing of MVCC Matt Miller <mattm@epx.com>
Re: Testing of MVCC Tom Lane <tgl@sss.pgh.pa.us>
Re: Testing of MVCC Matt Miller <mattm@epx.com>
Re: Testing of MVCC Matt Miller <mattm@epx.com>
Re: Testing of MVCC Michael Fuhr <mike@fuhr.org>
Re: Testing of MVCC Andrew Piskorski <atp@piskorski.com>
Re: Testing of MVCC Andrew Dunstan <andrew@dunslane.net>
Re: Testing of MVCC Tom Lane <tgl@sss.pgh.pa.us>
Re: Testing of MVCC Andrew Dunstan <andrew@dunslane.net>
Re: Testing of MVCC Tom Lane <tgl@sss.pgh.pa.us>
Re: Testing of MVCC Greg Stark <gsstark@mit.edu>
Re: Testing of MVCC Tom Lane <tgl@sss.pgh.pa.us>
Re: Testing of MVCC "Jim C. Nasby" <jnasby@pervasive.com>
Re: Testing of MVCC Greg Stark <gsstark@mit.edu>
Re: Testing of MVCC Tino Wildenhain <tino@wildenhain.de>
Re: Testing of MVCC Tom Lane <tgl@sss.pgh.pa.us>
Re: Testing of MVCC Tino Wildenhain <tino@wildenhain.de>
Re: Testing of MVCC Andrew Dunstan <andrew@dunslane.net>
Re: Testing of MVCC Tom Lane <tgl@sss.pgh.pa.us>
Re: Testing of MVCC Andrew Dunstan <andrew@dunslane.net>
Re: Testing of MVCC Tom Lane <tgl@sss.pgh.pa.us>
Re: Testing of MVCC Tom Lane <tgl@sss.pgh.pa.us>
Re: Testing of MVCC Kaare Rasmussen <kar@kakidata.dk>
Re: Testing of MVCC Greg Stark <gsstark@mit.edu>
Re: [GENERAL] Testing of MVCC Tom Lane <tgl@sss.pgh.pa.us>
Re: [GENERAL] Testing of MVCC Matt Miller <mattm@epx.com>
On Mon, 2005-08-08 at 16:59 -0400, Tom Lane wrote: > Matt Miller 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 = '' for update; where 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.
В списке pgsql-hackers по дате отправления