Re: Is the unfair lwlock behavior intended?

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Is the unfair lwlock behavior intended?
Дата
Msg-id 20160524222641.ygq2qo6xnw7af7dl@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: Is the unfair lwlock behavior intended?  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On 2016-05-24 17:20:48 -0400, Robert Haas wrote:
> On Tue, May 24, 2016 at 4:39 PM, Ants Aasma <ants.aasma@eesti.ee> wrote:
> > On Tue, May 24, 2016 at 9:03 AM, Tsunakawa, Takayuki
> > <tsunakawa.takay@jp.fujitsu.com> wrote:
> >> I encountered a strange behavior of lightweight lock in PostgreSQL 9.2.  That appears to apply to 9.6, too, as far
asI examine the code.  Could you tell me if the behavior is intended or needs fix?
 
> >>
> >> Simply put, the unfair behavior is that waiters for exclusive mode are overtaken by share-mode lockers who arrive
later.

Are you sure you're actually queued behind share locks, and not
primarily behind the lwlock's spinlocks? The latter is what I've seen in
similar cases.


> > 9.5 had significant LWLock scalability improvements. This might
> > improve performance enough so that exclusive lockers don't get
> > completely starved. It would be helpful if you could test if it's
> > still possible to trigger starvation with the new code.
> 
> 9.5 didn't just increase the scalability; it also whacked the fairness
> aspects of this code around.

True, but the difference isn't that big. As the commit says:


> and the fairness isn't really much worse than before, as we always
> allowed new shared lockers to jump the queue.

if you have lots of incoming locks, as it appears to be the case for th
OP, the fact that queued share locks are woken up earlier doesn't make
much of a difference.


Regards,

Andres



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

Предыдущее
От: Jeff Janes
Дата:
Сообщение: Re: effective_io_concurrency in 9.6beta
Следующее
От: Peter Geoghegan
Дата:
Сообщение: Re: Is the unfair lwlock behavior intended?