I use PostgreSQL 9.2, and I do not use explicit locking anywhere, neither LOCK
statement nor SELECT ... FOR UPDATE
. However, recently I got ERROR: 40P01: deadlock detected
. The query where deadlock was detected is wrapped in transaction block though. Anyway, how comes it?
相关问题
- Django distinct is not working
- PostgreSQL: left outer join syntax
- Connecting Python to a Heroku PostgreSQL DB?
- PostgreSQL - Deleting data that are older than an
- Does PLV8 support making http calls to other serve
相关文章
- postgresql 关于使用between and 中是字符串的问题
- postgresql 月份差计算问题
- Using boolean expression in order by clause
- MySQL 5.6 deadlock for locking the same rows twice
- Table valued Parameter Equivalent in Postgresql
- in redshift postgresql can I skip columns with the
- Oracle equivalent of PostgreSQL INSERT…RETURNING *
- PostgreSQL field data type for IPv4 addresses
You don't need any explicit
LOCK
to go into a deadlock. Here's a very simple demo from scratch with only INSERTs:Session #1 does:
Then session #2 does:
Then session #1 does:
And then the deadlock occurs:
The same could happen with simple UPDATEs or a combination of UPDATEs and INSERTs. These operations take implicit locks, and if they happen in different sessions in different orders, they may deadlock.
I would suspect hash indexes first.
hash
-indexes you have toB-tree
Serializable
isolation level if it seems appropriate.