Skip site navigation (1) Skip section navigation (2)

Re: stuck spin lock with many concurrent users

From: Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp>
To: Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp>
Cc: tgl(at)sss(dot)pgh(dot)pa(dot)us, pgsql-hackers(at)postgresql(dot)org
Subject: Re: stuck spin lock with many concurrent users
Date: 2001-06-26 10:02:42
Message-ID: 3B385DC2.A515C937@tpf.co.jp (view raw or flat)
Thread:
Lists: pgsql-hackers
Tatsuo Ishii wrote:
> 
> > Tatsuo Ishii wrote:
> > >
> > > > > Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp> 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.
> > >
> > > It appeared that the deadlock checking timer seems to be the source of
> > > the problem. With the default settings, it checks deadlocks every 1
> > > second PER backend.
> >
> > IIRC deadlock check was called only once per backend.
> 
> In my understanding the deadlock check is performed every time the
> backend aquires lock. Once the it aquires, it kill the timer. 

Yes, but deadlock check is needed only once and timer should
be disabled then also.

regards,
Hiroshi Inoue

In response to

pgsql-hackers by date

Next:From: John GrayDate: 2001-06-26 11:24:12
Subject: Re: Multi-entry indexes (with a view to XPath queries)
Previous:From: Tatsuo IshiiDate: 2001-06-26 09:50:38
Subject: Re: stuck spin lock with many concurrent users

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group