Re: [PATCH] LWLock self-deadlock detection

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [PATCH] LWLock self-deadlock detection
Дата
Msg-id 586995.1606359034@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [PATCH] LWLock self-deadlock detection  (Craig Ringer <craig.ringer@enterprisedb.com>)
Ответы Re: [PATCH] LWLock self-deadlock detection
Список pgsql-hackers
Craig Ringer <craig.ringer@enterprisedb.com> writes:
> On Wed, Nov 25, 2020 at 9:23 PM Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>
> wrote:
>> I'd prefer to make the lock self deadlock check run for production
>> builds, not just cassert builds.

I'd like to register a strong objection to spending any cycles whatsoever
on this.  If you're using LWLocks in a way that could deadlock, you're
doing it wrong.  The entire point of that mechanism is to be Light Weight
and not have all the overhead that the heavyweight lock mechanism has.
Building in deadlock checks and such is exactly the wrong direction.
If you think you need that, you should be using a heavyweight lock.

Maybe there's some case for a cassert-only check of this sort, but running
it in production is right out.

I'd also opine that checking for self-deadlock, but not any more general
deadlock, seems pretty pointless.  Careless coding is far more likely
to create opportunities for the latter.  (Thus, I have little use for
the existing assertions of this sort, either.)

            regards, tom lane



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

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: walsender bug: stuck during shutdown
Следующее
От: 曾文旌
Дата:
Сообщение: Re: [Proposal] Global temporary tables