Re: heavily contended lwlocks with long wait queues scale badly

Поиск
Список
Период
Сортировка
От Jonathan S. Katz
Тема Re: heavily contended lwlocks with long wait queues scale badly
Дата
Msg-id 985c9887-d492-7d1c-a735-fbcd06dafead@postgresql.org
обсуждение исходный текст
Ответ на Re: heavily contended lwlocks with long wait queues scale badly  (Andres Freund <andres@anarazel.de>)
Ответы Re: heavily contended lwlocks with long wait queues scale badly  (Nathan Bossart <nathandbossart@gmail.com>)
Список pgsql-hackers
On 11/20/22 2:56 PM, Andres Freund wrote:
> Hi,
> 
> On 2022-11-09 17:03:13 -0800, Andres Freund wrote:
>> On 2022-11-09 09:38:08 -0800, Andres Freund wrote:
>>> I'm on a hike, without any connectivity, Thu afternoon - Sun. I think it's OK
>>> to push it to HEAD if I get it done in the next few hours. Bigger issues,
>>> which I do not expect, should show up before tomorrow afternoon. Smaller
>>> things could wait till Sunday if necessary.
>>
>> I didn't get to it in time, so I'll leave it for when I'm back.
> 
> Took a few days longer, partially because I encountered an independent issue
> (see 8c954168cff) while testing.
> 
> I pushed it to HEAD now.

Thanks!

> I still think it might be worth to backpatch in a bit, but so far the votes on
> that weren't clear enough on that to feel comfortable.

My general feeling is "yes" on backpatching, particularly if this is a 
bug and it's fixable without ABI breaks.

My comments were around performing additional workload benchmarking just 
to ensure people feel comfortable that we're not introducing any 
performance regressions, and to consider the Feb 2023 release as the 
time to introduce this (vs. Nov 2022). That gives us ample time to 
determine if there are any performance regressions introduced.

Thanks,

Jonathan

Вложения

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

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: Damage control for planner's get_actual_variable_endpoint() runaway
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Damage control for planner's get_actual_variable_endpoint() runaway