Tatsuo Ishii wrote:
>
> > Tatsuo Ishii wrote:
> > >
> > > > > Tatsuo Ishii <t-ishii@sra.co.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
