Konstantin Osipov wrote:
> * Davi Arnaut <davi@stripped> [08/06/03 18:36]:
>> 2660 Davi Arnaut 2008-06-03
>> Bug#33362: Query cache invalidation (truncate) may hang
>> if cached query uses many tables
>>
>> The problem was that query cache would not properly cache
>> queries which used 256 or more tables but yet would leave
>> behind query cache blocks pointing to freed (destroyed)
>> data. Later when invalidating (due to a truncate) query cache
>> would attempt to grab a lock which resided in the freed data,
>> leading to hangs or undefined behavior.
>>
>> This was happening due to a improper return value from the
>> function responsible for registering the tables used in the
>> query (so the cache can be invalidated later if one of the
>> tables is modified). The function expected a return value of
>> type boolean (char, 8 bits) indicating success (1) or failure
>> (0) but the number of tables registered (unsigned int, 32 bits)
>> was being returned instead. This caused the function to return
>> failure for cases where it had actually succeed because when
>> a type (unsigned int) is converted to a narrower type (char),
>> the excess bits on the left are discarded. Thus if the 8
>> rightmost bits are zero, the return value will be 0 (failure).
>>
>> === modified file 'sql/sql_cache.cc'
>> --- a/sql/sql_cache.cc 2008-03-28 19:00:35 +0000
>> +++ b/sql/sql_cache.cc 2008-06-03 13:59:46 +0000
>> @@ -2746,7 +2746,7 @@ my_bool Query_cache::register_all_tables
>> tmp++)
>> unlink_table(tmp);
>> }
>> - return (n);
>> + return test(n);
>> }
>
> This is ok to push but is there any reason to keep the return
> value my_bool?
No reason other than to just fix the issue.
> I think all such places is a time bomb, as well as my_bool type
> itself.
Agree, will you review a mysql-6.0 cleanup patch removing all my_bool's
from sql_cache.cc (a C++ file!)?
Regards,
--
Davi Arnaut, Software Engineer
MySQL Server Runtime Team
Database Group, Sun Microsystems
