Re: stuck spin lock with many concurrent users

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