Greg Stark <gsstark@mit.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 ...
regards, tom lane