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