Re: stuck spin lock with many concurrent users

From: Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp>
To: tgl(at)sss(dot)pgh(dot)pa(dot)us
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: stuck spin lock with many concurrent users
Date: 2001-06-24 11:37:52
Message-ID: 20010624203752U.t-ishii@sra.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> > > 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2001-06-24 11:55:22 Re: Setuid functions
Previous Message Philip Warner 2001-06-24 11:32:25 Re: Setuid functions