[PATCH] LWLock self-deadlock detection

Поиск
Список
Период
Сортировка
От Craig Ringer
Тема [PATCH] LWLock self-deadlock detection
Дата
Msg-id CAGRY4nyyYarrwfc72gp5uDyA-wR+Tf6f9YnPhqDv_rw7R5oEYA@mail.gmail.com
обсуждение исходный текст
Ответы Re: [PATCH] LWLock self-deadlock detection
Список 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.
Вложения

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

Предыдущее
От: "osumi.takamichi@fujitsu.com"
Дата:
Сообщение: RE: Disable WAL logging to speed up data loading
Следующее
От: Craig Ringer
Дата:
Сообщение: Re: Add LWLock blocker(s) information