Re: Deadlock with pg_dump?
От | Tom Lane |
---|---|
Тема | Re: Deadlock with pg_dump? |
Дата | |
Msg-id | 26690.1161902708@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Deadlock with pg_dump? (Chris Campbell <chris@bignerdranch.com>) |
Ответы |
Re: Deadlock with pg_dump?
Re: Deadlock with pg_dump? Re: Deadlock with pg_dump? |
Список | pgsql-hackers |
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. 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
В списке pgsql-hackers по дате отправления: