> 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.
Nice idea. I will try that.
--
Tatsuo Ishii
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
- [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
