Re: thread safety on clients

Tom Lane wrote:
> Also, the reason why Bruce's mistake exposed this is interesting.
> Omitting the #define for ENABLE_THREAD_SAFETY does not actually break
> "pgbench -j" at all -- it has a fallback strategy that uses multiple
> subprocesses instead of multiple threads.  However, it has only one
> srandom() call, which occurs in the parent process before forking.
> This means that the subprocesses all start with the same random number
> state, which means they generate the same sequence of "random" account
> IDs to update

We just got that as a bug report the other day too, with suggested 
fixes:  http://archives.postgresql.org/pgsql-hackers/2009-12/msg00841.php

> I'm inclined to think this is bad, and we should fix pgbench to
> re-randomize after forking.  If we don't, we'll have synchronized
> behavior on some platforms and not others, which doesn't seem like a
> good idea.  On the other hand, if you did want that type of behavior,
> it's hard to see how you'd get it.  Is it worth trying to provide that
> as a (probably non-default) mode in pgbench?  If so, how would you
> do it on threaded platforms?
>   
It sounds like random pgbench run for a while would certainly expose the 
same thing you're concerned about eventually.  I doubt it's worth the 
trouble to codify a bug just because it found another bug (it's hard 
enough to maintain code that only has to work right).  If we want to 
stress this behavior, it would be easier to just test with a a bunch of 
clients going through a scale=1 database and use enough transactions to 
make update collisions likely.  I'm working on a guide to stress testing 
new alpha builds with pgbench that will be ready in time for alpha3.  I 
could easily add that as one of the suggested tests to run if you're 
concerned about getting more test coverage of that code path.

-- 
Greg Smith    2ndQuadrant   Baltimore, MD
PostgreSQL Training, Services and Support
greg@2ndQuadrant.com  www.2ndQuadrant.com