Hello Sergei and Konstantin!
Thank you for a review.
Will add an additional mutex.
Gleb.
Sergei Golubchik wrote:
> 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
>
