Re: heavily contended lwlocks with long wait queues scale badly

From: "Jonathan S(dot) Katz" <jkatz(at)postgresql(dot)org>
To: Andres Freund <andres(at)anarazel(dot)de>, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Yura Sokolov <y(dot)sokolov(at)postgrespro(dot)ru>
Subject: Re: heavily contended lwlocks with long wait queues scale badly
Date: 2022-11-21 15:31:14
Message-ID: 985c9887-d492-7d1c-a735-fbcd06dafead@postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2022-11-21 15:32:28 Re: Damage control for planner's get_actual_variable_endpoint() runaway
Previous Message Simon Riggs 2022-11-21 15:30:31 Re: Damage control for planner's get_actual_variable_endpoint() runaway