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

From Craig Ringer
Subject [PATCH] LWLock self-deadlock detection
Date
Msg-id CAGRY4nyyYarrwfc72gp5uDyA-wR+Tf6f9YnPhqDv_rw7R5oEYA@mail.gmail.com
Whole thread Raw
Responses Re: [PATCH] LWLock self-deadlock detection  (Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>)
List pgsql-hackers
Hi all

Here's a patch I wrote a while ago to detect and report when a LWLockAcquire() results in a simple self-deadlock due to the caller already holding the LWLock.

To avoid affecting hot-path performance, it only fires the check on the first iteration through the retry loops in LWLockAcquire() and LWLockWaitForVar(), and just before we sleep, once the fast-path has been missed.

I wrote an earlier version of this when I was chasing down some hairy issues with background workers deadlocking on some exit paths because ereport(ERROR) or elog(ERROR) calls fired when a LWLock was held would cause a before_shmem_exit or on_shmem_exit cleanup function to deadlock when it tried to acquire the same lock.

But it's an easy enough mistake to make and a seriously annoying one to track down, so I figured I'd post it for consideration. Maybe someone else will get some use out of it even if nobody likes the idea of merging it.

As written the check runs only for --enable-cassert builds or when LOCK_DEBUG is defined.
Attachment

pgsql-hackers by date:

Previous
From: "osumi.takamichi@fujitsu.com"
Date:
Subject: RE: Disable WAL logging to speed up data loading
Next
From: Craig Ringer
Date:
Subject: Re: Add LWLock blocker(s) information