No. See (explicit locking is not required to create a deadlock scenario): http://www.postgresql.org/docs/9.1/static/explicit-locking.html#LOCKING-DEADLOCKS htt

No. See (explicit locking is not required to create a deadlock scenario): http://www.postgresql.org/docs/9.1/static/explicit-locking.html#LOCKING-DEADLOCKS http://www.postgresql.org/docs/9.1/static/explicit-locking.h... Here's a (badly formatted) example: CREATE TABLE testing (value int, id serial); insert into testing values (1); insert into testing values (1); testing=# begin; BEGIN testing=# update testing set value = 2 where id = 1; UPDATE 1 (now in another session) BEGIN testing=# update testing set value = 2 where id = 2; UPDATE 1 (go back to original session) testing=# update testing set value = 2 where id = 2; UPDATE 1 (go back to second session) testing=# update testing set value = 2 where id = 1; ERROR: deadlock detected DETAIL: Process 11571 waits for ShareLock on transaction 2746675; blocked by process 11495. Process 11495 waits for ShareLock on transaction 2746676; blocked by process 11571. HINT: See server log for query details.