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 09:41:08
Message-ID: 3B3858B4.C02B53C6@tpf.co.jp (view raw or flat)
Thread:
Lists: pgsql-hackers
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.
It seems to have been changed between 7.0 and 7.1.
Does it take effect to disable timer at the beginging of
HandleDeadLock() ?

regards,
Hiroshi Inoue

In response to

Responses

pgsql-hackers by date

Next:From: Tatsuo IshiiDate: 2001-06-26 09:50:38
Subject: Re: stuck spin lock with many concurrent users
Previous:From: Tatsuo IshiiDate: 2001-06-26 08:53:04
Subject: Re: stuck spin lock with many concurrent users

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