Re: detecting deadlocks
От | Jonathan Ellis |
---|---|
Тема | Re: detecting deadlocks |
Дата | |
Msg-id | 00b601c1a374$2ed6fde0$4a050a0a@jellispc обсуждение исходный текст |
Ответ на | detecting deadlocks ("Jonathan Ellis" <jbe@familyellis.org>) |
Ответы |
Re: detecting deadlocks
|
Список | pgsql-general |
Tom Lane wrote: > "Jonathan Ellis" <jbe@familyellis.org> writes: > > I get this logged > > logger: ERROR: Deadlock detected. > > logger: ^ISee the lock(l) manual page for a possible cause. > > > but that's kind of useless to actually fix the problem. Is there a way to > > get it to log which two transactions are deadlocking? > > I think we could persuade the lock manager to return more info than it > does now, but I'm not sure how to translate the low-level info (backend > IDs and lock tags) into something useful to a user. How would you want > the other transactions to be identified? I don't know what's within the realm of possibility here, but something like this could help identify the problem * sql from both transactions that was deadlocked, i.e. the statement where the backend realized it couldn't keep executing * list of locks held by each (so you could guess what had preceeded) My deadlock is happening on a table that is updated in at least a dozen places, and I've tried to make sure transactions lock tables in the same order, but I must have missed something. It sure would be nice to be able to narrow it down some. -Jonathan
В списке pgsql-general по дате отправления: