Re: trying to make sense of deadlocks - Mailing list pgsql-general

From Tom Lane
Subject Re: trying to make sense of deadlocks
Date
Msg-id 29717.1234241535@sss.pgh.pa.us
Whole thread Raw
In response to trying to make sense of deadlocks  (Richard Yen <dba@richyen.com>)
Responses Re: trying to make sense of deadlocks
List pgsql-general
Richard Yen <dba@richyen.com> writes:
> It seems like all the deadlocks are for tuple (3,60), but strangely,
> tuple (3,60) on the account table doesn't exist.  Perhaps it was
> deleted?  According to the account table, the account with id = 39271
> (which the UPDATE statements call for) corresponds to tuple (3,15):

Is this PG 8.3?

What I'm guessing is happening is that (3,60) is where the updated
version of (3,15) gets put.  It never becomes visible to you because
the updating transaction never manages to commit due to the deadlock.
It would be possible/likely for the same CTID to be assigned over and
over in repeated trials if you're using 8.3 --- in prior versions this
theory gets a lot weaker because a vacuum pass would have to occur to
clean out the failed update tuple.

In any case what you seem to be looking at is updates of the same set
of two or more rows, but done in different orders by different
transactions.

            regards, tom lane

pgsql-general by date:

Previous
From: "Adam Rich"
Date:
Subject: Re: trying to make sense of deadlocks
Next
From: Richard Yen
Date:
Subject: Re: trying to make sense of deadlocks