Simon Riggs wrote: > On Thu, 2006-10-26 at 18:45 -0400, Tom Lane wrote: > > Chris Campbell <[EMAIL PROTECTED]> writes: > > > Is there additional logging information I can turn on to get more > > > details? I guess I need to see exactly what locks both processes > > > hold, and what queries they were running when the deadlock occurred? > > > Is that easily done, without turning on logging for *all* statements? > > > > log_min_error_statement = error would at least get you the statements > > reporting the deadlocks, though not what they're conflicting against. > > Yeh, we need a much better locking logger for performance analysis. > > We really need to dump the whole wait-for graph for deadlocks, since > this might be more complex than just two statements involved. Deadlocks > ought to be so infrequent that we can afford the log space to do this - > plus if we did this it would likely lead to fewer deadlocks. > > For 8.3 I'd like to have a log_min_duration_lockwait (secs) parameter > that would allow you to dump the wait-for graph for any data-level locks > that wait too long, rather than just those that deadlock. Many > applications experience heavy locking because of lack of holistic > design. That will also show up the need for other utilities to act > CONCURRENTLY, if possible.
Old email, but I don't see how our current output is not good enough? test=> lock a; ERROR: deadlock detected DETAIL: Process 6855 waits for AccessExclusiveLock on relation 16394 of database 16384; blocked by process 6795. Process 6795 waits for AccessExclusiveLock on relation 16396 of database 16384; blocked by process 6855. -- Bruce Momjian <[EMAIL PROTECTED]> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend