Re: deadlock debug methodology question

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

In response to

Responses

Browse pgsql-general by date

  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