A fix for Bug#6042 "constants propogation works olny once (prepared
statements)": reset item->marker in Item::cleanup, as it's used
in propogate_cond_constants. No test case as the only way I could
come up with to show the problem is EXPLAIN, and EXPLAIN is painful
to use in the test suite.
crashes server (prepared statements)": the bug was that all boolean
items always recovered its original arguments at statement cleanup
stage.
This collided with Item_subselect::select_transformer, which tries to
permanently change the item tree to use a transformed subselect instead of
original one.
So we had this call sequence for prepare:
mysql_stmt_prepare -> JOIN::prepare ->
Item_subselect::fix_fields -> the item tree gets transformed ->
Item_bool_rowready_func2::cleanup, item tree is recovered to original
state, while it shouldn't have been;
mysql_stmt_execute -> attempts to execute a broken tree -> crash.
Now instead of bluntly recovering all arguments of bool functions in
Item_bool_rowready_func2::cleanup, we recover only those
which were changed, and do it in one place.
There still would exist a possibility for a collision with subselect
tranformation, if permanent and temporary changes were performed at the
same stage.
But fortunately subselect transformation is always done first, so it
doesn't conflict with the optimization done by propogate_cond_constants.
Now we have:
mysql_stmt_prepare -> JOIN::prepare -> subselect transformation
permanently changes the tree -> cleanup doesn't recover anything,
because nothing was registered for recovery.
mysql_stmt_execute -> JOIN::prepare (the tree is already transformed,
so it doesn't change), JOIN::optimize ->
propogate_cond_constants -> temporary changes the item tree
with constants -> JOIN::execute -> cleanup ->
the changes done by propogate_cond_constants are recovered, as
they were registered for recovery.
crashes mysqld": implementation for a generic item tree modifications
registry. Every item tree modification which should be rolled back for
subsequent execution of a prepared statement or stored procedure should
be saved in the registry. All such modifications are rolled back at once
during cleanup stage of PS.
Actual fix for the bug just adds a call to register modifications to
convert_constant_item.
Post review fixes implemented.
character set introducer": add new item type to be returned before from
Item_param until it's value is set.
This way items like Item_bool_func2 and udf_handler won't treat this item
as constant literal when statement is prepared.
after Monty's review.
- Item_param was rewritten.
- it turns out that we can't convert string data to character set of
connection on the fly, because they first should be written to the binary
log.
To support efficient conversion we need to rewrite prepared statements
binlogging code first.
"mysql_send_long_data() API call is completely broken".
Now we are resetting some members (long_data_supplied/null_value...) of Item_param to its
initial state after each execution of prepared statement. We also manipulating
Item_param::maybe_null/null_value only via Item_param::set_* setters which makes code a bit
more robust.
table resolution".
Added members to Item_ident for storing original db, table and field
names since those that set later from Field have shorter life-time
than required by prep. stmt. So we need to restore original names in
Item_ident::cleanup(). Also now using special construnctor for creation
of Item_field from Field object that ensures that table and field name
have big enough life-time.
"Fix" for bug #2050 "10 to 1 performance drop with server 4.1.1"
Clean ups in implementation of caching of field number in table.
Added caching of table in which field is found in find_field_in_tables().
Actually it is not a bug but right behavior observed as pefomance
degradation after we have forced Item_field::fix_fields() to
re-execute each time when we are executing prep stmt.
This patch implements small optimization which heals this bad
behavior. We are caching field position in TABLE::field array in
Item's member and are using this position for speeding up field
lookups in fix_fields() in case of its re-execution.
