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). The solution is to simply return true (1) only if the number of registered table is greater than zero and false (0) otherwise. mysql-test/r/query_cache_merge.result: Add test case result for Bug#33362 mysql-test/t/query_cache_merge.test: Add test case for Bug#33362 sql/sql_cache.cc: Return 1 or 0 depending on the number of registered tables.
Showing
Please register or sign in to comment