Bruce, This looks like a similar error to what you received: StackOverflow<http://stackoverflow.com/questions/3040432/postgresql-implicit-lock-acquisition-from-foreign-key-constraint-evaluation>
More generally, deadlock happens because two sessions are trying to update the same table but holding locks to each other's records. Something like this: *SESSION 1* BEGIN; UPDATE posts SET comment = 'Some Comment' WHERE id = 1; -- Session 1 now holds a lock on post #1 *SESSION 2* BEGIN UPDATE posts SET comment = 'Another Comment' WHERE id = 2; -- Session 2 now holds a lock on post #2 *SESSION 1* SELECT * FROM posts WHERE id = 2; -- Session 1 now waits for Session 2 to finish it's transaction and release the lock *SESSION 2* SELECT * FROM posts WHERE id = 1; -- Session 2 now waits for Session 1 to finish it's transaction and release the lock ***DEADLOCK*** Neither can complete their transactions so PostgreSQL detects this situation and rolls back both transactions. Obviously that's a simple case... usually these kinds of things take you into cascading events with triggers, constraints or some other kind of order of operations. On Friday, May 25, 2012 7:08:35 PM UTC+1, Bruce Wade wrote: > > <class 'psycopg2.extensions.TransactionRollbackError'> deadlock detected > DETAIL: Process 20969 waits for ShareLock on tuple (10,126) of relation > 16935 of database 16386; blocked by process 20615. Process 20615 waits for > ShareLock on transaction 19960600; blocked by process 20124. Process 20124 > waits for ExclusiveLock on tuple (10,126) of relation 16935 of database > 16386; blocked by process 20969. HINT: See server log for query details. > CONTEXT: SQL statement "SELECT 1 FROM ONLY "public"."ads" x WHERE "id" > OPERATOR(pg_catalog.=) $1 FOR SHARE OF x" Any suggestions? > > -- > -- > Regards, > Bruce Wade > http://ca.linkedin.com/in/brucelwade > http://www.wadecybertech.com > http://www.fittraineronline.com - Fitness Personal Trainers Online > http://www.warplydesigned.com > >
