Re: algo for canceling a deadlocked transaction
Hello Tom, Thank you for the clarification! Regards, Thomas Le lun. 9 avr. 2018 à 17:04, Tom Lane a écrit : > Christophe Pettus writes: > >> On Apr 9, 2018, at 07:33, Thomas Poty wrote: > >> ok, and long answer ? is it random? > > > It's not literally random, but from the application point of view, it's > not predictable. For example, it's not always the one that opened first, > or any other consistent measure. > > It's whichever one runs the deadlock detector first after the circular > wait becomes established. For instance: > > * Process A takes lock L1 > > * Process B takes lock L2 > > * Process A tries to take lock L2, blocks > > * Process B tries to take lock L1, blocks (now a deadlock exists) > > Process A will run the deadlock detector one deadlock_timeout after > blocking. If that happens before B has blocked, then A will see > no deadlock and will go back to waiting. In that case, when B's > own deadlock_timeout expires and it runs the deadlock detector, > it will see the deadlock and fix it by canceling its own wait. > On the other hand, if B started to wait less than one deadlock_timeout > after A did, then A will be first to observe the deadlock and it will > cancel itself, not B. > > So you can't predict it unless you have a lot of knowledge about > the timing of events. You could probably make it more predictable > by making deadlock_timeout either very short or very long, but > neither of those are desirable things to do. > > regards, tom lane >
Re: algo for canceling a deadlocked transaction
Christophe Pettus writes: >> On Apr 9, 2018, at 07:33, Thomas Poty wrote: >> ok, and long answer ? is it random? > It's not literally random, but from the application point of view, it's not > predictable. For example, it's not always the one that opened first, or any > other consistent measure. It's whichever one runs the deadlock detector first after the circular wait becomes established. For instance: * Process A takes lock L1 * Process B takes lock L2 * Process A tries to take lock L2, blocks * Process B tries to take lock L1, blocks (now a deadlock exists) Process A will run the deadlock detector one deadlock_timeout after blocking. If that happens before B has blocked, then A will see no deadlock and will go back to waiting. In that case, when B's own deadlock_timeout expires and it runs the deadlock detector, it will see the deadlock and fix it by canceling its own wait. On the other hand, if B started to wait less than one deadlock_timeout after A did, then A will be first to observe the deadlock and it will cancel itself, not B. So you can't predict it unless you have a lot of knowledge about the timing of events. You could probably make it more predictable by making deadlock_timeout either very short or very long, but neither of those are desirable things to do. regards, tom lane
Re: algo for canceling a deadlocked transaction
> On Apr 9, 2018, at 07:33, Thomas Poty wrote: > > ok, and long answer ? is it random? It's not literally random, but from the application point of view, it's not predictable. For example, it's not always the one that opened first, or any other consistent measure. -- -- Christophe Pettus x...@thebuild.com
Re: algo for canceling a deadlocked transaction
Hello Stephen, > The short answer is "it's whichever one detected the deadlock." The > deadlock timeout fires after a lock has been held that long and if a > deadlock is detected then the process detecting it will be canceled. ok, and long answer ? is it random? > I'd strongly recommend reviewing your application and addressing > deadlocks by changing how the application acquires locks to be > consistent and to avoid lock escalation instead of worrying about how to > predict a deadlock- a properly designed and written application > shouldn't be causing deadlocks to happen in the first place. I didn't want to predict the deadlock happening. I only want to know if it is predictable to know which transaction will be canceled. Thank you 2018-04-09 15:51 GMT+02:00 Stephen Frost : > Greetings, > > * Thomas Poty (thomas.p...@gmail.com) wrote: > > My question is : In case of a deadlock between 2 transaction, how to > know > > which transaction will be canceled? Is it predictable? > > The short answer is "it's whichever one detected the deadlock." The > deadlock timeout fires after a lock has been held that long and if a > deadlock is detected then the process detecting it will be canceled. > > I'd strongly recommend reviewing your application and addressing > deadlocks by changing how the application acquires locks to be > consistent and to avoid lock escalation instead of worrying about how to > predict a deadlock- a properly designed and written application > shouldn't be causing deadlocks to happen in the first place. > > Thanks! > > Stephen >
Re: algo for canceling a deadlocked transaction
Greetings, * Thomas Poty (thomas.p...@gmail.com) wrote: > My question is : In case of a deadlock between 2 transaction, how to know > which transaction will be canceled? Is it predictable? The short answer is "it's whichever one detected the deadlock." The deadlock timeout fires after a lock has been held that long and if a deadlock is detected then the process detecting it will be canceled. I'd strongly recommend reviewing your application and addressing deadlocks by changing how the application acquires locks to be consistent and to avoid lock escalation instead of worrying about how to predict a deadlock- a properly designed and written application shouldn't be causing deadlocks to happen in the first place. Thanks! Stephen signature.asc Description: PGP signature
