Re: Race conditions, race conditions!

Поиск
Список
Период
Сортировка
От Jim C. Nasby
Тема Re: Race conditions, race conditions!
Дата
Msg-id 20050508170444.GB88920@decibel.org
обсуждение исходный текст
Ответ на Re: Race conditions, race conditions!  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Sat, May 07, 2005 at 07:20:48PM -0400, Tom Lane wrote:
> 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 ...

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@decibel.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?"


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Patch for collation using ICU
Следующее
От: Andrew - Supernews
Дата:
Сообщение: Re: Views, views, views! (long)