Re: [PATCH] LWLock self-deadlock detection

Поиск
Список
Период
Сортировка
От Peter Geoghegan
Тема Re: [PATCH] LWLock self-deadlock detection
Дата
Msg-id CAH2-WzkbCvgKrmw+f+1hwgXhmiv+UNRihotALXftUiNr=3VUKA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [PATCH] LWLock self-deadlock detection  (Heikki Linnakangas <hlinnaka@iki.fi>)
Ответы Re: [PATCH] LWLock self-deadlock detection
Список 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 по дате отправления:

Предыдущее
От: Stephen Frost
Дата:
Сообщение: Re: A few new options for CHECKPOINT
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Setof RangeType returns