Hello Tom, Thank you for the clarification!
Regards, Thomas Le lun. 9 avr. 2018 à 17:04, Tom Lane <t...@sss.pgh.pa.us> a écrit : > Christophe Pettus <x...@thebuild.com> writes: > >> On Apr 9, 2018, at 07:33, Thomas Poty <thomas.p...@gmail.com> 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 >
