On Thu, 2006-10-26 at 18:45 -0400, Tom Lane wrote:
> Chris Campbell <chris@bignerdranch.com> 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
