Hi! 18.07.2011 23:45, timour@askmonty.org пишет:

At file:///home/tsk/mprog/src/5.3-work/

------------------------------------------------------------ revno: 3115 revision-id: timour@askmonty.org-20110718204538-2976m25qh52g6l69 parent: igor@askmonty.org-20110717075207-sg6f40o1ps8mwxrj fixes bug(s): https://launchpad.net/bugs/782305 committer: timour@askmonty.org branch nick: 5.3-work timestamp: Mon 2011-07-18 23:45:38 +0300 message: Fix bug lp:782305

Analysis: Both the wrong result and the valgrind warning were a result of incomplete cleanup of the MIN/MAX subquery rewrite. At the first execution of the query, the non-aggregate subquery is transformed into an aggregate MIN/MAX subquery. During the fix_fields phase of the MIN/MAX function, it sets the property st_select_lex::with_sum_func to true.

The second execution of the query finds this flag to be ON. When optimization reaches the same MIN/MAX subquery transformation, it tests if the subquery is an aggregate or not. Since select_lex->with_sum_func == true from the previous execution, the transformation executes the second branch that handles aggregate subqueries. This substitutes the subquery Item into a Item_maxmin_subselect. At the same time elsewhere it is assumed that the subquery Item is of type Item_allany_subselect. Ultimately this results in casting the actual object to the wrong class, and calling the wrong any_value() method from empty_underlying_subquery().

Solution: Cleanup the st_select_lex::with_sum_func property in the case when the MIN/MAX transformation was performed for a non-aggregate subquery, so that the transformation can be repeated.

The patch is OK. SUBS_MAXMIN_ENGINE is really good name, thank you! [skip]