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. > [ Memo to hackers: why is it that log_min_error_statement = error > isn't the default? ] For production systems where we expect fewer ERRORs, each one is important, so this would be a good default. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match