问题
Suppose that two simultaneous transactions execute the following queries on a Postgresql DB:
Transaction A:
SELECT * FROM mytable WHERE id IN (1, 2, 3, 4) FOR UPDATE
Transaction B:
SELECT * FROM mytable WHERE id IN (6, 3, 2, 1) FOR UPDATE
Is it possible for a deadlock to occur due to Postgresql acquiring row locks in an inconsistent order? E.g. if Postgresql were to acquire row locks in the order the ids are given in this example, then there is a potential for deadlock.
Or is Postgresql internally intelligent enough to always acquire row locks in a way that simultaneous, discrete SELECT FOR UPDATE statements on the same table cannot deadlock each other (e.g. by always acquiring row locks in order of primary key)?
If Postgresql doesn't automatically prevent such deadlocks from occurring, is there a way to modify the queries to prevent such a situation (e.g. if in fact Postgresql acquires row locks in the order the ids are given, then consistently sorting the ids should prevent deadlock)?
Thanks for any help!
回答1:
Sorry, I had another answer but it was wrong.
The documentation states that an ORDER BY clause is applied before the FOR UPDATE clause. So the locks are acquired in whatever order the rows are selected (I have confirmed as such by testing). If you need to select them in a different order, you can use:
SELECT * FROM (SELECT * FROM table ORDER BY id FOR UPDATE) ORDER BY another_column;
You may want to try your question on the PostgreSQL mailing list.
回答2:
From http://www.postgresql.org/docs/9.1/static/explicit-locking.html:
PostgreSQL automatically detects deadlock situations and resolves them by aborting one of the transactions involved
That page uses an example involving UPDATEs, which are equivalent to SELECT ... FOR UPDATE with respect to locking.
来源：https://stackoverflow.com/questions/12825663/can-two-select-for-update-statements-on-the-same-table-cause-a-deadlock