"Orr, Steve" <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
