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
