The cause of the wrong result is that after the subquery execution
detects that it must generate a NULL row for an aggregate function,
the function do_select() calls:
while ((table= li++)) mark_as_null_row(table->table);
This marks all rows in the table as complete NULL rows. 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(), and the the call to Field::is_null()
returns true, resulting in a NULL for the MAX function.
The problem lines above were added by the fix for bug lp:613029.
It turns out that if this fix is removed, both the current bug, and lp:613029 are fixed. Therefore the fix is to remove the patch for bug lp:lp:613029, however, I have to understand what other patch have
fixed bug lp:613029.
Analysis;
The cause of the wrong result is that after the subquery execution
mark_ as_null_ row(table- >table) ;
detects that it must generate a NULL row for an aggregate function,
the function do_select() calls:
while ((table= li++))
This marks all rows in the table as complete NULL rows. 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(), and the the call to Field::is_null()
returns true, resulting in a NULL for the MAX function.
The problem lines above were added by the fix for bug lp:613029.
It turns out that if this fix is removed, both the current bug, and
lp:613029 are fixed. Therefore the fix is to remove the patch for bug
lp:lp:613029, however, I have to understand what other patch have
fixed bug lp:613029.