Re: heavily contended lwlocks with long wait queues scale badly - Mailing list pgsql-hackers

From Jonathan S. Katz
Subject Re: heavily contended lwlocks with long wait queues scale badly
Date
Msg-id 985c9887-d492-7d1c-a735-fbcd06dafead@postgresql.org
Whole thread Raw
In response to Re: heavily contended lwlocks with long wait queues scale badly  (Andres Freund <andres@anarazel.de>)
Responses Re: heavily contended lwlocks with long wait queues scale badly
List 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

Attachment

pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Damage control for planner's get_actual_variable_endpoint() runaway
Next
From: Tom Lane
Date:
Subject: Re: Damage control for planner's get_actual_variable_endpoint() runaway