> > > 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. > > Nice idea. I will try that. I got an interesting result. If I compile backend with -g (and without -O2), I get no stuck spin lock errors. However, if s_lock.c is compiled with -O2 enabled, I got the error again. It seems only s_lock.c is related to this phenomenon. -- Tatsuo Ishii ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
- [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
- Re: [HACKERS] stuck spin lock with many concurrent users Tom Lane
- Re: [HACKERS] stuck spin lock with many concurrent users Tom Lane