Re: Race conditions, race conditions!

On Sat, May 07, 2005 at 07:20:48PM -0400, Tom Lane wrote:
> Greg Stark <gsstark(at)mit(dot)edu> writes:
> > I wonder if there's an argument for building assertion-enabled builds with
> > code that randomly yields the processor some percentage of time before and
> > after taking a lock. It wouldn't catch every case but it might help.
>
> Seems like that would mainly help you find cases where you'd put a lock
> acquire or release a bit too late or too soon in a sequence of events;
> not cases where you'd failed to acquire a needed lock at all. It'd be
> more useful I think to have a facility that randomly stops backends for
> awhile regardless of exactly where they are in the code.
>
> A high-load test case actually does this to some extent, but the problem
> is you have little reproducibility and no assurance that execution
> stopped for long enough to let critical events happen elsewhere. The
> ideal facility I think would slow one backend much more than others,
> whereas high load still leaves them all making progress at about the
> same rate ...

Would setting different priorities/niceness on different backends during
the stress test help? It might not be perfect but it should be trivial
to accomplish...
--
Jim C. Nasby, Database Consultant decibel(at)decibel(dot)org
Give your computer some brain candy! www.distributed.net Team #1828

Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"