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

From Tom Lane
Subject Re: [PATCH] LWLock self-deadlock detection
Date
Msg-id 586995.1606359034@sss.pgh.pa.us
Whole thread Raw
In response to Re: [PATCH] LWLock self-deadlock detection  (Craig Ringer <craig.ringer@enterprisedb.com>)
Responses Re: [PATCH] LWLock self-deadlock detection  (Heikki Linnakangas <hlinnaka@iki.fi>)
List 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 by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: walsender bug: stuck during shutdown
Next
From: 曾文旌
Date:
Subject: Re: [Proposal] Global temporary tables