SCENARIO

Issue:
------
Queries with derived tables which used materialization were
stored in Query Cache without fully taking into account storage
engines for some tables used by them (specifically information
for underlying tables of derived table was disregarded).
So, cached results for such queries were used without check
against SEs which led to stale results sometimes.

This problem occurs when:
1) Rows are being inserted into a table (t1 for example)
   but they haven't been committed yet. Storage engine
   used is INNODB
2) Query with a derived table contains t1 as a base table.
3) Optimizer has chosen to materialize the derived table.

In this case Query Cache returned stale results for the query
after transaction commit.

Solution:
---------
When a derived table is present, no check is performed to
make sure that all the base tables qualify to be cached.
This has been corrected. If the query qualifies to be
cached, then the storage engine will be consulted at cache
lookup time.