The problem does NOT depend on configuration. The most important thing to know is: There is NO MAGIC CONFIGURATION PARAMETER to fix this problem. The default value here is 1 second, which is high enough to avoid pointless deadlock detection attempts, but is still short enough to fix the problem in a useful and timely manner. Why does PostgreSQL wait for some time before it steps in and fixes things? The reason is that deadlock detection is quite expensive, and therefore not immediately triggering it makes sense. If two transactions are in a conflict, PostgreSQL will not resolve the problem immediately, rather it will wait for deadlock_timeout and then trigger the deadlock detection algorithm to resolve the problem. The reason is that transactions have to wait for one another. Process 70713 waits for ShareLock on transaction 891718 blocked by process 70725.ĬONTEXT: while updating tuple (0,1) in relation "t_data" PostgreSQL waits (deadlock_timeout) and triggers deadlock detection after this timeout (not immediately)ĭETAIL: Process 70725 waits for ShareLock on transaction 891717 blocked by process 70713. Wants to lock the row locked by transaction id: now both are supposed to wait Has to wait until transaction 2 releases the lock on the row containing id = 2 Abort one transaction and commit the other transaction.Īs waiting infinitely is not an option, PostgreSQL will abort one of these transactions after some time ( deadlock_timeout).But what happens if transaction 1 has to wait for transaction 2 and transaction 2 has to wait for transaction 1? In that case, the system has two choices: ![]() It is perfectly fine if transaction 1 has to wait for transaction 2. The crux is that if data is updated in a different order, transactions might have to wait for one another to be finished. Test=# CREATE TABLE t_data (id int, data int) That’s sufficient to explain the basic principle of deadlocks. If you want to understand how a deadlock occurs, all you need is a table containing two lines. They also want to understand how a deadlock can be avoided and what software developers can do about it. Many people approach us because they want to understand what a deadlock is and how it can happen. But what does it really mean? How can we prevent a deadlock and how can we reproduce the problem? Let’s dive into PostgreSQL locking and understand what deadlock and deadlock_timeout really mean. Many applications can simply retry their transactions from the beginning.Many might have seen PostgreSQL issue the following error message: "ERROR: deadlock detected". They are a fact of life in transactional systems, and your applications should be designed to handle them.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |