I mentioned this a while back, now that 8.2 is out perhaps others will be more
interested in new code.
Currently Postgres regression tests only test functionality within a single
session. There are no regression tests that test the transaction semantics or
locking behaviour across multiple transactions.
I modified psql to allow you to open multiple connections and switch between
them with a sort of csh job control style interface. It actually works out
pretty well. It's fairly easy to write regression tests for basic 2-client or
3-client cases.
The actual user interface may need some discussion though. I didn't want to
play the name game so I just prefixed all my commands with "c" and figured we
can always rename them later.
And experience with actually writing the tests shows that the explicit \cwait
command which was needed to eliminate (in practice if not in theory) race
conditions in regression tests turns out to be more flexibility than
necessary. Since you end up having to insert one in precisely predictable
locations -- namely after every asynchronous command and after every
connection switch -- perhaps it would be simpler to just have a "\pset cwait"
command that automatically introduces timeouts in precisely those places.
A brief explanation including an example regression test (the SAVEPOINT
locking bug discovered recently) and the patch here:
http://community.enterprisedb.com/concurrent/index.html
-- Gregory Stark EnterpriseDB http://www.enterprisedb.com
