stark wrote: > Actually I was already looking into a related issue and have some work here > that may help with this. > > I wanted to test the online index build and to do that I figured you needed to > have regression tests like the ones we have now except with multiple database > sessions. So I hacked psql to issue queries asynchronously and allow multiple > database connections. That way you can switch connections while a blocked or > slow transaction is still running and issue queries in other transactions. > > I thought it was a proof-of-concept kludge but actually it's worked out quite > well. There were a few conceptual gotchas but I think I have a reasonable > solution for each.
I have had an idea for some time that is actually much simpler -- just launch several backends at once to do different things, and randomly send SIGSTOP and SIGCONT to each. If they keep doing whatever they are doing in infinite loops, and you leave it enough time, it's very likely that you'll get problems if the concurrent locking (or whatever) is not right. The nice thing about this is that it's completely random, i.e. you don't have to introduce individual stop points in the backend (which may themselves hide some bugs). It acts (or at least, I expect it to act) just like the kernel gave execution to another process. The main difference with your approach is that I haven't tried it. -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings
