From: | Bill Moran <wmoran(at)collaborativefusion(dot)com> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: deadlock debug methodology question |
Date: | 2008-05-22 18:57:37 |
Message-ID: | 20080522145737.2274bed9.wmoran@collaborativefusion.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
In response to "antiochus antiochus" <antiochus(dot)usa(at)gmail(dot)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(at)collaborativefusion(dot)com
Phone: 412-422-3463x4023
From | Date | Subject | |
---|---|---|---|
Next Message | antiochus antiochus | 2008-05-22 19:15:58 | Re: deadlock debug methodology question |
Previous Message | Brijesh Shrivastav | 2008-05-22 18:49:38 | XML Support related questions |