Tatsuo Ishii <[EMAIL PROTECTED]> writes: > In my understanding the deadlock check is performed every time the > backend aquires lock. Once the it aquires, it kill the timer. However, > under heavy transactions such as pgbench generates, chances are that > the checking fires, and it tries to aquire a spin lock. That seems the > situation. It could be that with ~1000 backends all waiting for the same lock, the deadlock-checking code just plain takes too long to run. It might have an O(N^2) or worse behavior in the length of the queue; I don't think the code was ever analyzed for such problems. Do you want to try adding some instrumentation to HandleDeadlock to see how long it runs on each call? regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
- Re: [HACKERS] stuck spin lock with many concurrent users Tom Lane
- Re: [HACKERS] stuck spin lock with many concurrent users Tatsuo Ishii
- Re: [HACKERS] stuck spin lock with many concurrent users Tom Lane
- Re: [HACKERS] stuck spin lock with many concurrent users Tatsuo Ishii
- Re: [HACKERS] stuck spin lock with many concurrent users Tatsuo Ishii
- Re: [HACKERS] stuck spin lock with many concurrent users Tom Lane
- Re: [HACKERS] stuck spin lock with many concurrent users Tatsuo Ishii
- Re: [HACKERS] stuck spin lock with many concurrent users Tatsuo Ishii
- Re: [HACKERS] stuck spin lock with many concurrent users Tom Lane
- Re: [HACKERS] stuck spin lock with many concurrent users Tatsuo Ishii
- Re: [HACKERS] stuck spin lock with many concurrent users Tom Lane
- Re: [HACKERS] stuck spin lock with many concurrent users Tom Lane
- Re: [HACKERS] stuck spin lock with many concurrent users Tatsuo Ishii