maria-developers team mailing list archive

[Gordan Bobic <gordan@xxxxxxxxxx>]

Just as an additional data point, the query does seem to eventually
complete (and the transaction it is in commits) after about 2 hours.
But 2 hours seems an excessively long time for "closing tables". It
is a simple INSERT ... SELECT ... ON DUPLICATE KEY UPDATE, with a few
triggers on the table being inserted into firing off. The SELECT on
it's own takes only seconds to complete. The UPDATEs fired off by the
triggers complete in milliseconds.

Gordan

On Wed, 20 Mar 2013 12:51:50 +0000, Gordan Bobic <gordan@xxxxxxxxxx> 
wrote:
> On Wed, 20 Mar 2013 13:20:28 +0100, Sergei Golubchik
> <serg@xxxxxxxxxxxx> wrote:
> > Hi, Gordan!
> >
> > On Mar 20, Gordan Bobic wrote:
> > > > On Mar 20, Gordan Bobic wrote:
> > > >>  I have a situation with MariaDB 10.0.0 where an INSERT INTO ...
> > > >>  SELECT query that takes 3 seconds to run ends up stuck in the
> > > >>  closing tables state for 15+ minutes while burning 100% of CPU.
> > > >>
> > >  Stack trace attached in a text file.
> > >  Does this provide enough information for a worthwhile bug report?
> >
> > Was this stack trace created when you had your problem with a stuck
> > query?
>
> Yes. And the same query is still stuck in the same state 35 minutes 
> later.
>
> I have attached a fresh stack trace.
>
> > Because it doesn't look like there's any thread stuck in the 
> > "closing
> > table" state.
>
> In which case the state shown in "show full processlist" is 
> incorrect.
> Note that I think that helps.
>
> > There's one event running, a couple of idle connection threads, a 
> > couple
> > of dead connection thread (waiting in the thread cache for 
> > resurrection),
> > and internal service threads, aria, innodb, signal thread, etc.
>
> The one event that is running must be it, then. I specifically 
> disabled
> everything else on the box (slaves, event schduler) to get a clean 
> trace.
>
> Gordan