Re: deadlock debug methodology question

Поиск
Список
Период
Сортировка
От Bill Moran
Тема Re: deadlock debug methodology question
Дата
Msg-id 20080522145737.2274bed9.wmoran@collaborativefusion.com
обсуждение исходный текст
Ответ на deadlock debug methodology question  ("antiochus antiochus" <antiochus.usa@gmail.com>)
Ответы Re: deadlock debug methodology question
Список pgsql-general
In response to "antiochus antiochus" <antiochus.usa@gmail.com>:
>
> I have a deadlock situation, two transactions waiting on each other to
> complete. Based on the details below, would anyone have recommendations for
> me, please?

I have a theory on deadlocks, and that theory is that it's damn near
impossible to track them all down, so your best bet is to wrap all
SQL calls in a function that detects deadlock and sleep/retries.

[snip]

> Careful inspection of these (unfortunately complex) queries seems to
> indicate row-level locks are acquired in consistent order, assuming that any
> command of the type
>
> update tt where ....
>
> will always lock rows in a consistent order (can someone confirm that it is
> necessarily the case).

I believe that assertion is incorrect.  Without seeing your entire
query, I can only speculate, but unless you have an explicit ordering
clause, there's no guarantee what order rows will be accessed in.

Try putting an explicit ORDER BY in the queries and see if the problem
goes away.

--
Bill Moran
Collaborative Fusion Inc.
http://people.collaborativefusion.com/~wmoran/

wmoran@collaborativefusion.com
Phone: 412-422-3463x4023

В списке pgsql-general по дате отправления:

Предыдущее
От: Reece Hart
Дата:
Сообщение: Re: Short-circuiting FK check for a newly-added field
Следующее
От: "Brijesh Shrivastav"
Дата:
Сообщение: XML Support related questions