Fixed LP bug #802860.

This crashing bug could manifest itself at execution of join queries
over materialized derived tables with IN subquery predicates in the
where clause. If for such a query the optimizer chose to use duplicate
weed-out with duplicates in a materialized derived table and chose to
employ join cache the the execution could cause a crash of the server.
It happened because the JOIN_CACHE::init method assumed  that the value
of TABLE::file::ref is set at the moment when the method was called 
for the employed join cache. It's true for regular tables, but it's 
not true for materialized derived tables that are filled now at the
first access to them, i.e. after the JOIN_CACHE::init has done its job.

To fix this problem for any ROWID field of materialized derived table
the procedure that copies fields from record buffers into the employed
join buffer first checks whether the value of TABLE::file::ref has 
been set for the table, and if it's not so the procedure sets this value.

1 files changed, 1 insertions, 0 deletions

diff --git a/sql/sql_join_cache.h b/sql/sql_join_cache.h
index f87cdcec649..f5d64d5530a 100644
--- a/sql/sql_join_cache.h
+++ b/sql/sql_join_cache.h
@@ -16,6 +16,7 @@
 #define CACHE_STRIPPED  2        /* field stripped of trailing spaces */
 #define CACHE_VARSTR1   3        /* short string value (length takes 1 byte) */ 
 #define CACHE_VARSTR2   4        /* long string value (length takes 2 bytes) */
+#define CACHE_ROWID     5        /* ROWID field */
 
 /*
   The CACHE_FIELD structure used to describe fields of records that