Re: Deadlock with pg_dump?

Simon Riggs wrote:
> 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.

Old email, but I don't see how our current output is not good enough?
test=> lock a;ERROR:  deadlock detectedDETAIL:  Process 6855 waits for AccessExclusiveLock on relation 16394 ofdatabase
16384;blocked by process 6795.Process 6795 waits for AccessExclusiveLock on relation 16396 of database16384; blocked by
process6855.
 

--  Bruce Momjian  <bruce@momjian.us>          http://momjian.us EnterpriseDB
http://www.enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +