Tatsuo Ishii <[EMAIL PROTECTED]> writes: >>> How can I check it? >> >> The 'stuck' message should at least give you a code location... > FATAL: s_lock(0x2ac2d016) at spin.c:158, stuck spinlock. Aborting. Hmm, that's SpinAcquire, so it's one of the predefined spinlocks (and not, say, a buffer spinlock). You could try adding some debug logging here, although the output would be voluminous. But what would really be useful is a stack trace for the stuck process. Consider changing the s_lock code to abort() when it gets a stuck spinlock --- then you could gdb the coredump. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
- [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 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