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 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-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
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2006-10-26 23:23:12 | Re: Deadlock with pg_dump? |
Previous Message | Jim C. Nasby | 2006-10-26 22:29:11 | Re: Deadlock with pg_dump? |
From | Date | Subject | |
---|---|---|---|
Next Message | Jeremy Drake | 2006-10-26 22:58:07 | psql \lo_* quiet mode patch |
Previous Message | Jim C. Nasby | 2006-10-26 22:29:11 | Re: Deadlock with pg_dump? |