Skip site navigation (1) Skip section navigation (2)

Re: Deadlock with pg_dump?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Chris Campbell <chris(at)bignerdranch(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Deadlock with pg_dump?
Date: 2006-10-26 22:45:08
Message-ID: 26690.1161902708@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
Chris Campbell <chris(at)bignerdranch(dot)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.
Still, if you're seeing multiple occurrences per day, that would
probably let you build up a good picture of all the involved operations
over a couple of days.

[ Memo to hackers: why is it that log_min_error_statement = error
isn't the default? ]

Unless your applications are issuing actual LOCK TABLE commands, it's
really hard to see how pg_dump could be involved.  It doesn't take
anything stronger than AccessShareLock, and shouldn't be holding any
tuple-level locks at all.

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Alvaro HerreraDate: 2006-10-26 23:23:12
Subject: Re: Deadlock with pg_dump?
Previous:From: Jim C. NasbyDate: 2006-10-26 22:29:11
Subject: Re: Deadlock with pg_dump?

pgsql-patches by date

Next:From: Jeremy DrakeDate: 2006-10-26 22:58:07
Subject: psql \lo_* quiet mode patch
Previous:From: Jim C. NasbyDate: 2006-10-26 22:29:11
Subject: Re: Deadlock with pg_dump?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group