Re: Is the unfair lwlock behavior intended?

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Is the unfair lwlock behavior intended?
Дата
Msg-id CA+TgmoYuHXs5+wwgZqLbRvKwsLrf809z_o+gS6BKZP_SW0sxsw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Is the unfair lwlock behavior intended?  (Andres Freund <andres@anarazel.de>)
Ответы Re: Is the unfair lwlock behavior intended?  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
On Tue, May 24, 2016 at 6:50 PM, Andres Freund <andres@anarazel.de> wrote:
> Now we potentially could mark individual lwlocks as being fair
> locks. But which ones would those be? Certainly not ProcArrayLock, it's
> way too heavily contended.

I think this is looking at the problem from the wrong angle.  The OP's
complaint is pretty fair: a 30-second wait for ProcArrayLock is
horrendous, and if that's actually something that is happening with
any significant regularity on well-configured systems, we need to fix
it somehow.  Whether FIFO queueing on LWLocks is the right way to fix
it is a separate question, and I agree that the answer is probably
"no" ... although it does strike me that Amit's work on group XID
clearing might make that a lot more palatable, since you won't
normally have more than one exclusive waiter in the queue at a time.
But regardless of that, I don't think we can just say "oh, well,
sometimes the system becomes totally unresponsive for more than 30
seconds, but we don't care".  We have to care about that.

What I think we need to understand better from is Tsunakawa-san is (1)
whether this behavior still occurs in 9.6 and (2) what sort of test
case is required to produce it.  Depending on how extreme that test
case is, we can decide how much of a problem we think this is.  And we
can test potential solutions to see whether and to what degree they
address it, as well as how they affect throughput.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



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

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: [PROPOSAL] Move all am-related reloption code into src/backend/access/[am-name] and get rid of relopt_kind
Следующее
От: Robert Haas
Дата:
Сообщение: Re: pg_bsd_indent - improvements around offsetof and sizeof