Backport into build-200909301147-5.0.84sp1
> ------------------------------------------------------------ > revno: 2791.2.3 > revision-id: joro@sun.com-20090827114042-h55n7qp9990bl6ge > parent: anurag.shekhar@sun.com-20090831073231-e55y1hsck6n08ux8 > committer: Georgi Kodinov <joro@sun.com> > branch nick: B46749-5.0-bugteam > timestamp: Thu 2009-08-27 14:40:42 +0300 > message: > Bug #46749: Segfault in add_key_fields() with outer subquery level > field references > > This error requires a combination of factors : > 1. An "impossible where" in the outermost SELECT > 2. An aggregate in the outermost SELECT > 3. A correlated subquery with a WHERE clause that includes an outer > field reference as a top level WHERE sargable predicate > > When JOIN::optimize detects an "impossible WHERE" it will bail out > without doing the rest of the work and initializations. It will not > call make_join_statistics() as well. And make_join_statistics fills > in various structures for each table referenced. > When processing the result of the "impossible WHERE" the query must > send a single row of data if there are aggregate functions in it. > In this case the server marks all the aggregates as having received > no rows and calls the relevant Item::val_xxx() method on the SELECT > list. However if this SELECT list happens to contain a correlated > subquery this subquery is evaluated in a normal evaluation mode. > And if this correlated subquery has a reference to a field from the > outermost "impossible where" SELECT the add_key_fields will mistakenly > consider the outer field reference as a "local" field reference when > looking for sargable predicates. > But since the SELECT where the outer field reference refers to is not > completely initialized due to the "impossible WHERE" in this level > we'll get a NULL pointer reference. > Fixed by making a better condition for discovering if a field is "local" > to the SELECT level being processed. > It's not enough to look for OUTER_REF_TABLE_BIT in this case since > for outer references to constant tables the Item_field::used_tables() > will return 0 regardless of whether the field reference is from the > local SELECT or not.
Showing
Please register or sign in to comment