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.
Showing
Please register or sign in to comment