> On Mon, 16 Mar 1998, David Gould wrote:
> > The generic way to do this is
> > select( NULL_FDSET, NULL_FDSET, NULL_FDSET, &delaytime, NULL);
> > Delay time may be 0, but a random value between 0 and say 30 msec seems
> > to be optimal. Hard busy wait spinlocks cause huge performance problems with
> > heavily loaded systems and lots of postgres backends. Basically one backend
> > ends up with the lock and gets scheduled out holding it, every else queues
> > up busywaiting behind this one. But the backend holding the lock cannot
> > release it until all the other backeds waiting on the lock exhaust a full
> > timeslice busywaiting. Get 20 of these guys going (like on a busy website) and
> > the system pretty much stops doing any work at all.
> > I say we should get this in as soon as we can.
> Can you submit an appropriate patch that can be included in the mega-patch
> to be created on Sunday?
Just a warning that this is not going to be easy. We have OS-specific
code for spinlocks in include/storage/s_lock.h and
backend/storage/buffer/s_lock.c. So each S_LOCK macro call has to have
its test-and-set logic de-coupled with its while-lock-fail-try-again
logic. Most of them are easy, but some like VAX:
#define S_LOCK(addr) __asm__("1: bbssi $0,(%0),1b": :"r"(addr))
are hard to de-couple. Now, I did not know we supported NetBSD on VAX.
Does it work, anyone? Can I remove it?
This is going to be pretty tough to test on every platform we support,
so if it is done now, it will have to be done carefully.
Bruce Momjian | 830 Blythe Avenue
maillist(at)candle(dot)pha(dot)pa(dot)us | Drexel Hill, Pennsylvania 19026
+ If your life is a hard drive, | (610) 353-9879(w)
+ Christ can be your backup. | (610) 853-3000(h)
In response to
pgsql-hackers by date
|Next:||From: Thomas G. Lockhart||Date: 1998-03-17 03:21:04|
|Subject: Re: [QUESTIONS] Re: [HACKERS] text should be a blob field|
|Previous:||From: Bruce Momjian||Date: 1998-03-17 03:02:49|
|Subject: Re: [HACKERS] Unique index using hash?|