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
g...@2ndquadrant.com www.2ndQuadrant.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
