Re: [PATCH] LWLock self-deadlock detection

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Craig Ringer <craig(dot)ringer(at)enterprisedb(dot)com>
Cc: Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>, ashutosh(dot)bapat(at)enterprisedb(dot)com, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] LWLock self-deadlock detection
Date: 2020-11-26 02:50:34
Message-ID: 586995.1606359034@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Craig Ringer <craig(dot)ringer(at)enterprisedb(dot)com> writes:
> On Wed, Nov 25, 2020 at 9:23 PM Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message 曾文旌 2020-11-26 02:54:46 Re: [Proposal] Global temporary tables
Previous Message Alvaro Herrera 2020-11-26 02:45:04 Re: walsender bug: stuck during shutdown