On Fri, Dec 11, 2009 at 6:08 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I wrote:
> I'll commit a fix for that shortly, but this reminds me once again that
> the EvalPlanQual logic is desperately under-tested in our normal
> regression testing. We really need some kind of testing infrastructure
> that would let us exercise concurrent-update cases a bit more than "not
> at all".
If i went back and cleaned up the parallel psql patch we would be able
to write tests which tested basic concurrent functionality such as
transactions blocking when they're supposed to. But that wouldn't
catch something like this I don't think, not unless it got triggered
pretty reliably by a simple evalplanqual recheck.
> 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?
Well it's pretty useless for benchmarking unless someone comes up with
a different plan for resolving these kinds of conflicts and we wanted
to compare the costs. But it's clearly something we should do for
testing for precisely this kind of bug. EvalPlanQual could trigger all
kinds of bugs throughout the executor and it would be worth having
something like this to check for them.
I believe it's possible to give at least one of the random number
generating apis a preallocated buffer for it to use to store the
generator state, that could easily be per-thread state along with the
connection and other state. I'm not sure which api that was and
whether it's as portable or as good a generator as what we're using
now though.
--
greg
