Re: [PATCH] LWLock self-deadlock detection - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: [PATCH] LWLock self-deadlock detection
Date
Msg-id CAH2-WzkbCvgKrmw+f+1hwgXhmiv+UNRihotALXftUiNr=3VUKA@mail.gmail.com
Whole thread Raw
In response to Re: [PATCH] LWLock self-deadlock detection  (Heikki Linnakangas <hlinnaka@iki.fi>)
Responses Re: [PATCH] LWLock self-deadlock detection  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
On Fri, Nov 27, 2020 at 10:22 AM Heikki Linnakangas <hlinnaka@iki.fi> wrote:
> I've made the mistake of forgetting to release an LWLock many times,
> leading to self-deadlock. And I just reviewed a patch that did that this
> week [1]. You usually find that mistake very quickly when you start
> testing though, I don't think I've seen it happen in production.

+1. The fact that you don't get deadlock detection with LWLocks is a
cornerstone of the whole design. This assumption is common to all
database systems (LWLocks are generally called latches in the database
research community, but the concept is exactly the same).

> So yeah, I agree it's not worth spending cycles on this. Maybe it would
> be worth it if it's really simple to check, and you only do it after
> waiting X seconds. (I haven't looked at this patch at all)

-1 for that, unless it's only for debug builds. Even if it is
practically free, it still means committing to the wrong priorities.
Plus the performance validation would be very arduous as a practical
matter.

We've made LWLocks much more scalable in the last 10 years. Why
shouldn't we expect to do the same again in the next 10 years? I
wouldn't bet against it. I might even do the opposite (predict further
improvements to LWLocks).

-- 
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: A few new options for CHECKPOINT
Next
From: Tom Lane
Date:
Subject: Re: Setof RangeType returns