Re: [HACKERS] Re: [PATCHES] patches for 6.2.1p6 - Mailing list pgsql-hackers

From The Hermit Hacker
Subject Re: [HACKERS] Re: [PATCHES] patches for 6.2.1p6
Date
Msg-id Pine.BSF.3.96.980316224713.304B-100000@thelab.hub.org
Whole thread Raw
In response to Re: [HACKERS] Re: [PATCHES] patches for 6.2.1p6  (dg@illustra.com (David Gould))
Responses Re: [HACKERS] Re: [PATCHES] patches for 6.2.1p6
List pgsql-hackers
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?

Thanks...

Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org


pgsql-hackers by date:

Previous
From: "Thomas G. Lockhart"
Date:
Subject: Re: [QUESTIONS] UPDATE statement ORACLE 6 compatible
Next
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] Unique index using hash?