Sergey, Please review the below patch. As discussed, all other solutions that try to keep the call to mark_as_null_row() lead to a chicken-egg-like problem that is tricky to solve. Since I am not sure it is worth solving, I suggest the below simple solution. Timour ------------------------------------------------------------ revno: 3108 revision-id: timour@askmonty.org-20110714095300-bwi0z7x542cj2avd parent: timour@askmonty.org-20110714072218-hty7xnwn1dxmn9a3 fixes bug(s): https://launchpad.net/bugs/777691 committer: timour@askmonty.org branch nick: 5.3-work timestamp: Thu 2011-07-14 12:53:00 +0300 message: Fix bug lp:777691 Analysis: For some of the re-executions of the correlated subquery the where clause is false. In these cases the execution of the subquery detects that it must generate a NULL row because of implicit grouping. In this case the subquery execution reaches the following code in do_select(): while ((table= li++)) mark_as_null_row(table->table); This code marks all rows in the table as complete NULL rows. In the example, when evaluating the field t2.f10 for the second row, all bits of Field::null_ptr[0] are set by the previous call to mark_as_null_row(). Then the call to Field::is_null() returns true, resulting in a NULL for the MAX function. Thus the lines above are not suitable for subquery re-execution because mark_as_null_row() changes the NULL bits of each table field, and there is no logic to restore these fields. Solution: The call to mark_as_null_row() was added by the fix for bug lp:613029. Therefore removing the fix for lp:613029 corrects this wrong result. At the same time the test for lp:613029 behaves correctly because the changes of MWL#89 result in a different execution path where: - the constant subquery is evaluated via JOIN::exec_const_cond - detecting that it has an empty result triggers the branch if (zero_result_cause) return_zero_rows() - return_zero_rows() calls mark_as_null_row().