From: | Richard Yen <dba(at)richyen(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: trying to make sense of deadlocks |
Date: | 2009-02-10 06:20:04 |
Message-ID: | 8DD506D1-A0B9-4009-9582-AE512EA79972@richyen.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
在 Feb 9, 2009 8:52 PM 時, Tom Lane 寫到:
> Richard Yen <dba(at)richyen(dot)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?
>>
Yes, I'm using 8.3.5
> 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.
That makes sense. I should've thought of that earlier.
> 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.
Thanks for the tip!
--Richard
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2009-02-10 06:46:54 | Re: ora2pg or dbi_link ? |
Previous Message | Tom Lane | 2009-02-10 04:52:15 | Re: trying to make sense of deadlocks |