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.
(Bug #4315: GROUP_CONCAT with ORDER BY returns strange results for TEXT fields
Bug #5564: Strange behaviour with group_concat and distinct
Bug #5970: group_concat doesn't print warnings)
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.
Fix bug #5137: if innodb_file_per_table was specified, CREATE TEMPORARY TABLE ... TYPE=InnoDB said that cannot find path specified, and made mysqld to exit(1)
to auto_increment in 4.1".
Now we are enforcing NO_AUTO_VALUE_ON_ZERO mode during ALTER TABLE only
if we are converting one auto_increment column to another auto_increment
column (this also includes most common case when we don't do anything
with such column).
Also now when we convert some column to TIMESTAMP NOT NULL column with
ALTER TABLE we convert NULL values to current timestamp, (as we do this
in INSERT). One can still get old behavior by setting system TIMESTAMP
variable to 0.
introduced during implementation of TIMESTAMP columns, which are able
to store NULLs (Unfortunately it is impossible to write test case for
this. Kudos to Holyfoot for noticing it!)
Raise maximum column prefix len to 767 bytes, so that MySQL can create a column prefix index of 255 UTF-8 characters (each takes 3 bytes at the maximum); add comments about why innobase_get_at_most_n_mbchars() works ok
dict0mem.h:
Raise maximum column prefix len to 767 bytes, so that MySQL can create a column prefix index of 255 UTF-8 characters (each takes 3 bytes at the maximum)
row0mysql.c:
If MySQL tries to create a column prefix index longer that 255 UTF-8 characters, give an error, and drop the table from the InnoDB internal data dictionary. MySQL did not drop the table there in its own error handling.
