Hi, Konstantin!
On Feb 08, Konstantin Osipov wrote:
> * Gleb Shchepa <gshchepa@stripped> [08/11/12 13:51]:
> > 2714 Gleb Shchepa 2008-11-12
> > Bug #38816: kill + flush tables with read lock + stored
> > procedures causes crashes!
> >
> > The problem of that bugreport was mostly fixed by the
> > patch for bug 38691.
> > However, attached test case focused on another crash or
> > valgrind warning problem: SHOW PROCESSLIST query accesses
> > freed memory of SP instruction that run in a parallel
> > connection.
>
> Since when did we agree to protect the assignment of
> thd->query/query_length with LOCK_thread_count?
>
> If we decided to do that, why don't you change alloc_query() and
> other places as well?
>
> Serg, I support this approach, do you?
I don't.
Using a global mutex to change a thread-local variable (which is changes
very often) if a too high price to pay for a protection against a rarely
run SHOW PROCESSLIST.
You can be sure that in a short while after this fix PAE team will
submit a bugreport about contention on this mutex, and this fix will
have to be redone.
There are better solutions.
The first that comes to my mind - use a dedicated per-thread mutex to
protect thd->query and thd->query_length. It's not the best solution,
but a simplest one, for sure.
If we'd have fast rwlocks we could use a global LOCK_thread_count
rwlock. Every thread would take it in a shared mode when modifying its
own data, and SHOW PROCESSLIST would take it in exclusive mode when
readon other threads data.
There could be other solutions too, just cannot think of anything on
Sunday evening :)
Regards / Mit vielen Grüßen,
Sergei
--
__ ___ ___ ____ __
/ |/ /_ __/ __/ __ \/ / Sergei Golubchik <serg@stripped>
/ /|_/ / // /\ \/ /_/ / /__ Principal Software Engineer/Server Architect
/_/ /_/\_, /___/\___\_\___/ Sun Microsystems GmbH, HRB München 161028
<___/ Sonnenallee 1, 85551 Kirchheim-Heimstetten
Geschäftsführer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Boemer
Vorsitzender des Aufsichtsrates: Martin Häring
