Question

Recently, we encountered a dead lock problem. Two part of our system will update the same table in similar time, one update (name it “UP1”) several rows in a transaction, and the other(name it “UP2”) use a sql like “update … where id in (…)”.

It seems like it’s because that, the ids in sql “update … where id in (…)” are out of order,e.g. “5,6,2,3,4,1”; and in the transaction, update action will act in this order “1,2,3,4,5,6”. When “UP1” update the id “1,2,3,4” and the “UP2” update id “5,6”, the “UP1” want the id 5 which is locked by “UP2”, and the “UP2” want the id 2 which is locked by the “UP1”, so the dead lock comes out.

My question is, is the db lock rows one by one, and only release them when the sql or transaction is done? If not, why can not lock all the rows at the beginning of transaction or the “where id in (…)” sql, and why can not they release the updated row one by one?

Look forward to any helpful replies, thx.

Answer 1

You are pretty much on the right track. With the default Read Committed Isolation Level PostgreSQL acquires locks along the way and releases them when the transaction is committed or rolled back.

If you can make sure that all UPDATE operations update rows in the same order you will never run into deadlocks. Have you tried to making UP1 update rows in ascending order and sorting the IN list for UP2 the same way?

If you cannot guarantee synchronized updates, you may be interested in the Serializable Isolation Level. It is the strictest isolation level and may slow down your queries a bit, especially under heavy concurrency. But it should prevent the errors you see. Also, be prepared to retry transactions due to serialization failures.

For this, start your transaction with:

BEGIN ISOLATION LEVEL SERIALIZABLE;