The bug is present only in 4.1, will be null-merged to 5.0
For InnoDB, check value of thd->transaction.all.innodb_active_trans instead of thd->transaction.stmt.innobase_tid to see if we really need to rollback.
mysql-test/r/innodb_mysql.result:
Added testcase for bug #22728 "Handler_rollback value is growing"
mysql-test/t/innodb_mysql.test:
Added testcase for bug #22728 "Handler_rollback value is growing"
sql/handler.cc:
For InnoDB, check value of thd->transaction.all.innodb_active_trans instead of thd->transaction.stmt.innobase_tid to see if we really need to rollback.
The bug was as follows: When merge_key_fields() encounters "t.key=X OR t.key=Y" it will
try to join them into ref_or_null access via "t.key=X OR NULL". In order to make this
inference it checks if Y<=>NULL, ignoring the fact that value of Y may be not yet known.
The fix is that the check if Y<=>NULL is made only if value of Y is known (i.e. it is a
constant).
TODO: When merging to 5.0, replace used_tables() with const_item() everywhere in merge_key_fields().
mysql-test/r/innodb_mysql.result:
Testcase for BUG16798
mysql-test/t/innodb_mysql.test:
Testcase for BUG16798
sql/sql_select.cc:
BUG#16798: Inapplicable ref_or_null query plan and bad query result on random occasions
In merge_key_fields() don't call val->is_null() if the value of val is not known.
Use files innodb_mysql.[test|result] instead.
mysql-test/t/innodb.test:
This file is to be used by Innobase only.
mysql-test/r/innodb_mysql.result:
New BitKeeper file ``mysql-test/r/innodb_mysql.result''
Use this file instead of innodb.result.
mysql-test/t/innodb_mysql.test:
New BitKeeper file ``mysql-test/t/innodb_mysql.test''
Use this file instead of innodb.test.
