This fix changes the character set used within the
IBMDB2I handler to hash table names to information
about open tables. Previously, tables with names
that differed only in letter case would hash to the
same data structure. This caused incorrect behavior
or errors when two such tables were in use simultaneously.
mysql-test/suite/ibmdb2i/r/ibmdb2i_bug_49329.result:
Bug#49329 example (and other) engines use wrong collation for open tables hash
Result file for the test case.
mysql-test/suite/ibmdb2i/t/ibmdb2i_bug_49329.test:
Bug#49329 example (and other) engines use wrong collation for open tables hash
Test case for the bug fix.
storage/ibmdb2i/ha_ibmdb2i.cc:
Bug#49329 example (and other) engines use wrong collation for open tables hash
change the character set used within the IBMDB2I
handler to hash table names to information about
open tables.
The help text for --init-slave=name:
"Command(s) that are executed when a slave connects to this master".
This text indicate that the --init-slave option is set on a master
server, and the master server passes the option's argument to slave
which connects to it. This is wrong. Actually the --init-slave option
just can be set on a slave server, and then the slave server executes
the argument each time the SQL thread starts.
Correct the help text for --init-slave option as following:
"Command(s) that are executed by a slave server each time the SQL thread starts."
sql/mysqld.cc:
Correct the help text for --init-slave option.
The help text for --init-slave=name:
"Command(s) that are executed when a slave connects to this master".
This text indicate that the --init-slave option is set on a master
server, and the master server passes the option's argument to slave
which connects to it. This is wrong. Actually the --init-slave option
just can be set on a slave server, and then the slave server executes
the argument each time the SQL thread starts.
Correct the help text for --init-slave option as following:
"Command(s) that are executed by a slave server each time the SQL thread starts."
sql/mysqld.cc:
Correct the help text for --init-slave option.
SPATIAL and FULLTEXT indexes don't support algorithm
selection.
Disabled by creating a special grammar rule for these
in the parser.
Added some encasulation of duplicate parser code.
A few problems were found in the fix for bug 43668:
1) Comparison of the YEAR column with NULL always returned TRUE;
2) Comparison of the YEAR column with constants always returned
unpredictable result;
3) Unnecessary conversion warnings when comparing a non-integer
constant with a NULL value in the YEAR column;
The problems described above have been resolved with an
exception: zero (i.e. invalid) YEAR column value comparison
with 00 or 2000 still fail (it is not a regression and it was
not a regression), so MIN/MAX on YEAR column containing zero
value still fail.
mysql-test/r/type_year.result:
Test case for bug #49480.
mysql-test/t/type_year.test:
Test case for bug #49480.
sql/item_cmpfunc.cc:
- The get_year_value() function has been modified to make its
return value compatible with the get_datetime_value() return
value (i.e. to convert numeric values into the YYYY0000000000
(YYYY-00-00 00:00:00) form.
- The Arg_comparator::set_cmp_func method has been modified to
use the get_year_value function if get_datetime_value() is not
applicable.
From now only 2 cases have a special processing there:
* both comparing items have MYSQL_TYPE_YEAR field type
or
* one item have is MYSQL_TYPE_YEAR and other one is
is_datetime()-compliant.
- New helper function try_year_cmp_func() has been
added for the better code readability to call from
Arg_comparator::set_cmp_func().
- The Arg_comparator::compare_year method has been removed
since get_year_value() is compatible with the old
Arg_comparator::compare_datetime method that doesn't have
problems #1-#3 (see whole patch entry commentary).
sql/item_cmpfunc.h:
- New helper function try_year_cmp_func() has been
added for the better code readability to call from
Arg_comparator::set_cmp_func().
- Unnecessary Arg_comparator::year_as_datetime and
Arg_comparator::compare_year() declarations have been
removed.
mysql-test/include/kill_query.inc:
Error 1034 can be generated when change MyISAM table indexes was interrupted
mysql-test/r/rpl_killed_ddl.result:
table t4 may not exists because the ALTER above was interrupted
mysql-test/t/rpl_killed_ddl.test:
table t4 may not exists because the ALTER above was interrupted
Arg_comparator uses Item_cache objects to store constants being compared when
they're need a type conversion. Because this cache wasn't initialized properly
Arg_comparator might produce wrong comparison result.
The Arg_comparator::cache_converted_constant function now initializes cache
prior to usage.
mysql-test/r/select.result:
Added a test case for he bug#49489.
mysql-test/t/select.test:
Added a test case for he bug#49489.
sql/item_cmpfunc.cc:
Bug#49489: Uninitialized cache led to a wrong result.
The Arg_comparator::cache_converted_constant function now initializes cache
prior to usage.
This fix has been proposed by Sergey Petrunya and has been contributed
under SCA by sca@askmonty.org.
The cause for this valgrind error is that in the function
add_cond_and_fix() in sql_select.cc an Item_cond_and object is
created. This is marked as fixed but does not have a correct
table_map() attribute. Later, in make_join_select(), if
engine_condition_pushdown is in use, this table map is used and
results in the valgrind error.
The fix is to add a call to update_used_tables() in add_cond_and_fix()
so that the table map is updated correctly.
This patch is tested by multiple existing tests (e.g. the tests
innodb_mysql, innodb, fulltext, compress all produces this valgrind
warning/error without this fix).
sql/sql_select.cc:
In add_cond_and_fix() add a call to update_used_tables() to ensure
the table map is updated.
WL#3951 - MyISAM: Additional Error Logs for Data Corruption
Fixed partition_repair_myisam.test.
mysql-test/suite/parts/t/partition_repair_myisam.test:
Suppress some extra warnings produced by MyISAM.
There are three issues that caused rpl_killed_ddl fails sporadically
in pb2:
1) thd->clear_error() was not called before create Query event
if operation is executed successfully.
2) DATABASE d2 might do exist because the statement to CREATE or
ALTER it was killed
3) because of bug 43353, kill the query that do DROP FUNCTION or
DROP PROCEDURE can result in SP not found
This patch fixed all above issues by:
1) Called thd->clear_error() if the operation succeeded.
2) Add IF EXISTS to the DROP DATABASE d2 statement
3) Temporarily disabled testing DROP FUNCTION/PROCEDURE IF EXISTS.
mysql-test/t/rpl_killed_ddl.test:
DATABASE d2 might not exists, add IF EXITS to the DROP statement
sql/sql_db.cc:
Called thd->clear_error() if the operation succeeded
Bug#35591 FLUSH PRIVILEGES caused a crash
A race condition on the privilege hash tables (proc_priv_hash
and func_priv_hash) caused one thread to try to delete elements
that had already been deleted by another thread.
The bug was caused by reading and saving the pointers to
the hash tables outside mutex protection. This led to an
inconsistency where a thread copied a pointer to a hash,
another thread did the same, the first thread then deleted
the hash, and the second then crashed when it in turn tried to
delete the deleted hash.
The fix is to ensure that operations on the shared hash structures
happens under mutex protection (moving the locking up a little)
Part 2 :
There was a special optimization on the ref access method for
ORDER BY ... DESC that was set without actually looking on the type of the
selected index for ORDER BY.
Fixed the SELECT ... ORDER BY .. DESC (it uses a different code path compared
to the ASC that has been fixed with the previous fix).
Implemented a new INFORMATION_SCHEMA table, which is intended to
provide information about tablespaces.
mysql-test/r/information_schema.result:
Updated test result according to WL#2511. With this WL
I_S has new TABLESPACES schema.
mysql-test/r/information_schema_db.result:
Updated test result according to WL#2511. With this WL
I_S has new TABLESPACES schema.
mysql-test/r/mysqlshow.result:
Updated test result according to WL#2511. With this WL
I_S has new TABLESPACES schema.
mysql-test/suite/funcs_1/r/is_columns_is.result:
Updated test result according to WL#2511. With this WL
I_S has new TABLESPACES schema.
mysql-test/suite/funcs_1/r/is_tables_is.result:
Updated test result according to WL#2511. With this WL
I_S has new TABLESPACES schema.
sql/handler.h:
Added SCH_TABLESPACES to enum_schema_tables.
sql/mysql_priv.h:
Added human readable definitions for I_S.TABLESPACES field
identifiers.
sql/sql_show.cc:
Added I_S.TABLESPACES schema. The code which handles I_S.FILES
is capable to handle I_S.TABLESPACES as well. Thus we reuse
this code and let functions/variables have more generic names.
The problem is not actually related to 2byte collation IDs.
The same crash happens if you change the collation ID in
mysql-test/str_data/Index.xml to a value smaller than 256.
Crash happened in SQL parser, because the "ident_map" and "state_map"
arrays were not initialized in loadable utf8 collations.
Fix: adding proper initialization of the "ident_map" and "state_map"
members for loadable utf8 collations.
{PROCEDURE|FUNCTION} FROM ...'
The master would hit an assertion when binary log was
active. This was due to the fact that the thread's diagnostics
area was being cleared before writing to the binlog,
independently of mysql_routine_grant returning an error or
not. When mysql_routine_grant was to return an error, the return
value and the diagnostics area contents would
mismatch. Consequently, neither my_ok would be called nor an
error would be signaled in the diagnostics area, eventually
triggering the assertion in net_end_statement.
We fix this by not clearing the diagnostics area at binlogging
time.
