Re: DeadLocks..., DeadLocks... - Mailing list pgsql-general

From Gregory Stark
Subject Re: DeadLocks..., DeadLocks...
Date
Msg-id 87ps3xsigy.fsf@oxford.xeocode.com
Whole thread Raw
In response to Re: DeadLocks..., DeadLocks...  (Tom Allison <tom@tacocat.net>)
Responses Re: DeadLocks..., DeadLocks...  (Tom Allison <tom@tacocat.net>)
List pgsql-general
The insert is deadlocking against the update delete.

The problem is that the insert has to lock the records to be sure they aren't
deleted. This prevents the update for updating them. But the update has
already updated some other records which the insert hasn't referred to yet.
When the insert tries to insert a record referring to those it can't lock them
before they're already locked by the update and you have a deadlock.

Do you really need the update at all? Do you use the last_seen field for
anything other than diagnostics?

You could try breaking the update up into separate transactions instead of a
single batch statement. That would perform poorly but never deadlock.

You could try to order them both but I don't know if that's possible. UPDATE
doesn't take an ORDER BY clause. I suppose you could execute the update
statement as separate queries within a single transaction in whatever order
you want which would avoid the performance issue of issuing hundreds of
transactions while allowing you to control the order.

"Tom Allison" <tom@tacocat.net> writes:

> 2007-06-14 19:50:35 EDT LOG:  statement: insert into history_token(history_idx,
> token_idx)
>         select values.history_idx, values.token_idx
>         from ( values
>
(2703,260),(2703,31789),(2703,1518),(2703,59),(2703,555),(2703,4),(2703,66447),(2703,8178),(2703,64),(2703,132),(2703,6126),(2703,135),(2
>
703,69),(2703,9166),(2703,629),(2703,73),(2703,74),(2703,2271),(2703,78),(2703,493),(2703,8164),(2703,211),(2703,8166),(2703,84),(2703,60608),(2703,217),(2703,
>
88),(2703,8207),(2703,161),(2703,33518),(2703,220),(2703,222),(2703,446),(2703,2188),(2703,336),(2703,1197),(2703,166),(2703,1537),(2703,28),(2703,168),(2703,2
>
481),(2703,1081),(2703,99),(2703,100),(2703,172),(2703,8209),(2703,231),(2703,1900),(2703,344),(2703,104),(2703,24694),(2703,106),(2703,37),(2703,107),(2703,17
>
9),(2703,8203),(2703,85629),(2703,3671),(2703,98970),(2703,8187),(2703,187),(2703,306),(2703,254),(2703,415),(2703,256),(2703,257),(2703,98975),(2703,98976),(2
> 703,98977),(2703,98978) ) as values(history_idx, token_idx)
>         left outer join history_token ht using (history_idx, token_idx)
>         where ht.history_idx is null


>
> 2007-06-14 19:50:35 EDT ERROR:  deadlock detected
> 2007-06-14 19:50:35 EDT DETAIL:  Process 17253 waits for ShareLock on
> transaction 303949; blocked by process 17229.
>         Process 17229 waits for ShareLock on transaction 303950; blocked by
> process 17253.
> 2007-06-14 19:50:35 EDT STATEMENT:  update tokens set last_seen = now() where
> token_idx in
> (260,31789,1518,59,555,4,66447,8178,64,132,6126,135,69,9166,629,73,7
>
4,2271,78,493,8164,211,8166,84,60608,217,88,8207,161,33518,220,222,446,2188,336,1197,166,1537,28,168,2481,1081,99,100,172,98963,8209,231,1900,344,104,24694,106
> ,37,107,179,8203,85629,3671,8187,187,306,254,415,256,257,98968,98969,98970,98971)
> 2007-06-14 19:50:35 EDT LOG:  disconnection: session time: 0:00:13.810
> user=spam database=spam host=127.0.0.1 port=38126

--
  Gregory Stark
  EnterpriseDB          http://www.enterprisedb.com


pgsql-general by date:

Previous
From: Alban Hertroys
Date:
Subject: Re: Q: Tree traversal with SQL query?
Next
From: Tomasz Ostrowski
Date:
Subject: Re: Historical Data Question