On Fri, 4 Nov 2005, Jim C. Nasby wrote:
On Fri, Nov 04, 2005 at 05:26:25PM -0500, Andrew Dunstan wrote:
Well, for things like race conditions I don't know that you can create
reproducable test cases. My point was that this bug was exposed by
databases with workloads that involved very high transaction rates. I
know in the case of my client this is due to some sub-optimal design
decisions, and I believe the other case was similar. My suggestion is
that having a test that involves a lot of row-by-row type operations
that generate a very high transaction rate would help expose these kinds
of bugs.
Of course if someone can come up with a self-contained reproducable test
case for this race condition that would be great as well. :)
These conditions make it quite unsuitable for buildfarm, which is
designed as a thin veneer over the postgres build process, and intended
to run anywhere you can build postgres.
Maybe you could use one of the Linux labs, since your client is on RHEL.
I'm not worried about my client, I'm just thinking of a way to better
ferret out bugs like this. And there's no real reason why something like
this couldn't be part of regression, or an additional build target.
For all the talk about "couldn't it be part of regression", I haven't seen
anyone submit a patch that would test for it ... since I believe both you
and Tom have both stated that "for things like race conditions, I don't
know that you can create reproducable cases", can you submit a patch for
how you propose this should be added to the regression tests?
----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
