Re: Race conditions, race conditions!

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Greg Stark <gsstark(at)mit(dot)edu>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Race conditions, race conditions!
Date: 2005-05-07 23:20:48
Message-ID: 6380.1115508048@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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 ...

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Neil Conway 2005-05-07 23:22:55 Re: pl/pgsql enabled by default
Previous Message Tom Lane 2005-05-07 23:13:50 Re: pl/pgsql enabled by default