Re: Server error and deadlocks

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Server error and deadlocks
Дата
Msg-id 15918.1042558274@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Server error and deadlocks  ("Orr, Steve" <sorr@rightnow.com>)
Ответы Re: Server error and deadlocks  (Andrew Sullivan <andrew@libertyrms.info>)
Список pgsql-general
"Orr, Steve" <sorr@rightnow.com> writes:
> I suspect table locks but are there any database level tracing
> tools to show the SQL? Will the trace_locks and debug_deadlocks parameters
> help and how do I use them?

I do not think those will help you; they are low-level debugging aids
and are probably far too verbose to be useful for tracing an occasional
application problem.  Besides which, they're not even compiled in by
default.

It seems to me that it would be appropriate for DeadLockCheck to emit
more information about the problem it's found than just "there's a
deadlock".  How do people feel about reporting the detected cycle as
a series of NOTICE messages?  It would look pretty similar to the
pg_locks view:

NOTICE:  Proc <pid> waits for <lockmode> on <rel> <db>; blocked by <pid>
NOTICE:  Proc <pid> waits for <lockmode> on <rel> <db>; blocked by <pid>
NOTICE:  Proc <pid> waits for <lockmode> on <rel> <db>; blocked by <pid>
ERROR: Deadlock detected

If that seems acceptable, I could code it up in short order.  While I
wouldn't want to apply it to the REL7_3_STABLE branch, I see no reason
Steve wouldn't be able to use the patch locally to identify his problem.

            regards, tom lane

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

Предыдущее
От: Christoph Dalitz
Дата:
Сообщение: Re: how to check if a temp table exists?
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Vacuum verbose output?