Re: Testing with concurrent sessions
От | Marko Tiikkaja |
---|---|
Тема | Re: Testing with concurrent sessions |
Дата | |
Msg-id | 4B460847.6010702@cs.helsinki.fi обсуждение исходный текст |
Ответ на | Re: Testing with concurrent sessions (Craig Ringer <craig@postnewspapers.com.au>) |
Ответы |
Re: Testing with concurrent sessions
|
Список | pgsql-hackers |
On 2010-01-07 11:50 +0200, Craig Ringer wrote: > On 7/01/2010 9:15 AM, Robert Haas wrote: >> Doing this without DBI is going to be ten times harder than doing it >> with DBI. Are we really sure that's not a viable option? > > At this point, I'm personally wondering if it's worth putting together a > simple (ish) C program that reads a file describing command > interleavings on n connections. It fires up one thread per connection > required, then begins queuing commands up for the threads to execute in > per-thread fifo queues. The input file may contain synchronization > points where two or more explicitly specified threads (or just all > threads) must finish all their queued work before they may be given more. > CONN conn1: dbname=regress, user=regress > CONN conn2: dbname=regress, user=regress > STMT conn1: SELECT blah blah; > STMT conn2: UPDATE blah blah; > SYNC conn1, conn2 > > etc. Or alternately one-file-per-connection (which would be handy if one > connection has *lots* of commands and others only occasional ones) - the > only trouble there being how to conveniently specify synchronization points. I had a similar syntax in mind, but instead of using threads, just execute the file in order using asynchronous connections. Regards, Marko Tiikkaja
В списке pgsql-hackers по дате отправления: