> 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. However,
under heavy transactions such as pgbench generates, chances are that
the checking fires, and it tries to aquire a spin lock. That seems the
situation.
--
Tatsuo Ishii
