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 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
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
From | Date | Subject | |
---|---|---|---|
Next Message | John Gray | 2001-06-26 11:24:12 | Re: Multi-entry indexes (with a view to XPath queries) |
Previous Message | Tatsuo Ishii | 2001-06-26 09:50:38 | Re: stuck spin lock with many concurrent users |