Re: Testing of MVCC
От | Jim C. Nasby |
---|---|
Тема | Re: Testing of MVCC |
Дата | |
Msg-id | 20050822183804.GW95876@pervasive.com обсуждение исходный текст |
Ответ на | Re: Testing of MVCC (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Testing of MVCC
|
Список | pgsql-hackers |
On Tue, Aug 16, 2005 at 12:24:34AM -0400, Tom Lane wrote: > Greg Stark <gsstark@mit.edu> writes: > > So why bother with driving multiple invocations of psql under > > Expect. Just use DBD::Pg to open as many connections as you want and > > issue whatever queries you want. > > The bit that I think is missing in DBI is "issue a command and don't > wait for the result just yet". Without that, you cannot for instance > stack up several waiters for the same lock, as you might wish to do to > verify that they get released in the correct order once the original > lock holder goes away. Or stack up some conflicting waiters and check > to see if deadlock is detected when it should be ... or contrariwise, > not signalled when it should not be. There's lots of stuff you can > do that isn't exactly probing for race conditions, yet would be awfully > nice to check for in a routine test suite. > > I might be wrong though, not being exactly a DBI guru ... can this > sort of thing be done? Even if it can't be done, would it be reasonable to spawn multiple perl processes, each of which handles one database connection? I suspect it wouldn't be too hard to write a daemon in perl that would sit between the test code and a pile of DBI connections. -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com 512-569-9461
В списке pgsql-hackers по дате отправления: