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.
BTW, I just realized that part of the answer to Tom's musing about why
this hasn't been seen before now is that few (if any) regular users are
running with asserts turned on, so odds are good that they'd never know
if this problem occured or not. Further argument for trying to test this
on the buildfarm and/or enabling assertions by default, IMHO.
--
Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
