- 24 Aug, 2010 2 commits
-
-
Alexey Kopytov authored
-
Alexey Kopytov authored
within query The server could crash after materializing a derived table which requires a temporary table for grouping. When destroying the temporary table used to execute a query for a derived table, JOIN::destroy() did not clean up Item_fields pointing to fields in the temporary table. This led to dereferencing a dangling pointer when printing out the items tree later in the outer SELECT. The solution is an addendum to the patch for bug37362: in addition to cleaning up items in tmp_all_fields3, do the same for items in tmp_all_fields1, since now we have an example where this is necessary. mysql-test/r/join.result: Added test cases for bug#55568 and a duplicate bug #54468. mysql-test/t/join.test: Added test cases for bug#55568 and a duplicate bug #54468. sql/field.cc: Make sure field->table_name is not set to NULL in Field::make_field() to avoid assertion failure in Item_field::make_field() after cleaning up items (the assertion fired in udf.test when running the test suite with the patch applied). sql/sql_select.cc: In addition to cleaning up items in tmp_all_fields3, do the same for items in tmp_all_fields1. Introduce a new helper function to avoid code duplication. sql/sql_select.h: Introduce a new helper function to avoid code duplication in JOIN::destroy().
-
- 20 Aug, 2010 7 commits
-
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Georgi Kodinov authored
KILL_BAD_DATA is returned Two problems discovered with the LEAST()/GREATEST() functions: 1. The check for a null value should happen even after the second call to val_str() in the args. This is important because two subsequent calls to the same Item::val_str() may yield different results. Fixed by checking for NULL value before dereferencing the string result. 2. While looping over the arguments and evaluating them the loop should stop if there was an error evaluating so far or the statement was killed. Fixed by checking for error and bailing out.
-
- 19 Aug, 2010 3 commits
-
-
unknown authored
-
MySQL Build Team authored
-
Mattias Jonsson authored
-
- 18 Aug, 2010 1 commit
-
-
unknown authored
'CREATE TABLE IF NOT EXISTS ... SELECT' behaviour BUG#55474, BUG#55499, BUG#55598, BUG#55616 and BUG#55777 are fixed in this patch too. This is the 5.1 part. It implements: - if the table exists, binlog two events: CREATE TABLE IF NOT EXISTS and INSERT ... SELECT - Insert nothing and binlog nothing on master if the existing object is a view. It only generates a warning that table already exists. mysql-test/r/trigger.result: Ather this patch, 'CREATE TABLE IF NOT EXISTS ... SELECT' will not insert anything if the creating table already exists and is a view. sql/sql_class.h: Declare virtual function write_to_binlog() for select_insert. It's used to binlog 'create select' sql/sql_insert.cc: Implement write_to_binlog(); Use write_to_binlog() instead of binlog_query() to binlog the statement. if the table exists, binlog two events: CREATE TABLE IF NOT EXISTS and INSERT ... SELECT sql/sql_lex.h: Declare create_select_start_with_brace and create_select_pos. They are helpful for binlogging 'create select' sql/sql_parse.cc: Do nothing on master if the existing object is a view. sql/sql_yacc.yy: Record the relative postion of 'SELECT' in the 'CREATE ...SELECT' statement. Record whether there is a '(' before the 'SELECT' clause.
-
- 16 Aug, 2010 1 commit
-
-
Sunny Bains authored
-
- 13 Aug, 2010 3 commits
-
-
Georgi Kodinov authored
An user assignment variable expression that's evaluated in a logical expression context (Item::val_bool()) can be pre-calculated in a temporary table for GROUP BY. However when the expression value is used after the temp table creation it was re-evaluated instead of being read from the temp table due to a missing val_bool_result() method. Fixed by implementing the method.
-
Georgi Kodinov authored
The server was not checking for errors generated during the execution of Item::val_xxx() methods when copying data to the group, order, or distinct temp table's row. Fixed by extending the copy_funcs() to return an error code and by checking for that error code on the places copy_funcs() is called. Test case added.
-
Georgi Kodinov authored
variable assignments The assert() that is firing is checking if expressions that can't be null return a NULL when evaluated. MAKEDATE() function can return NULL if the second argument is less then or equal to 0. Thus its nullability depends not only on the nullability of its arguments but also on their values. Fixed by (overoptimistically) setting MAKEDATE() to be nullable despite the nullability of its arguments. Test added. Had to update one test result to reflect the metadata change.
-
- 11 Aug, 2010 1 commit
-
-
Martin Hansson authored
feature The test for bug no 50939 was put in range.test which isn't such a good idea since it requires partitioning. Fixed by moving the test case to partitioning_range.test.
-
- 10 Aug, 2010 2 commits
-
-
Georgi Kodinov authored
-
Georgi Kodinov authored
Updated the README file.
-
- 09 Aug, 2010 1 commit
-
-
Jon Olav Hauglid authored
INSERT IGNORE ... SELECT ... UNION SELECT ... This assert was triggered by INSERT IGNORE ... SELECT. The assert checks that a statement either sends OK or an error to the client. If the bug was triggered on release builds, it caused OK to be sent to the client instead of the correct error message (in this case ER_FIELD_SPECIFIED_TWICE). The reason the assert was triggered, was that lex->no_error was set to TRUE during JOIN::optimize() because of IGNORE. This causes all errors to be ignored. However, not all errors can be ignored. Some, such as ER_FIELD_SPECIFIED_TWICE will cause the INSERT to fail no matter what. But since lex->no_error was set, the critical errors were ignored, the INSERT failed and neither OK nor the error message was sent to the client. This patch fixes the problem by temporarily turning off lex->no_error in places where errors cannot be ignored during processing of INSERT ... SELECT. Test case added to insert.test.
-
- 06 Aug, 2010 4 commits
-
-
Gleb Shchepa authored
The CONVERT_TZ function crashes the server when the timezone argument is an empty SET field value. 1) The CONVERT_TZ may find a timezone string in the tz_names hash. 2) A string representation of the empty SET is a String of zero length with the NULL pointer. 3) If the key argument length is zero, hash functions do comparison using the length of the record being compared against. I.e. a zero-length String buffer is an invalid argument for hash search functions, and if String points to NULL buffer, hashcmp() fails with SEGV accessing that memory. The my_tz_find function has been modified to treat empty Strings as invalid timezone values to skip unnecessary hash search. mysql-test/r/timezone2.result: Test case for bug #55424. mysql-test/t/timezone2.test: Test case for bug #55424. sql/sql_string.h: Bug #55424: convert_tz crashes when fed invalid data Added "const" modifier to String::is_empty(). sql/tztime.cc: Bug #55424: convert_tz crashes when fed invalid data The my_tz_find function has been modified to treat empty Strings as invalid timezone values to skip unnecessary hash search.
-
Georgi Kodinov authored
read_rnd_buffer_size Applied the updated description from Paul's patch.
-
Bjorn Munch authored
Undo workaround as fix is being merged in
-
Bjorn Munch authored
-
- 05 Aug, 2010 4 commits
-
-
Georgi Kodinov authored
failures on sparc64.
-
Martin Hansson authored
file .\item_subselect.cc, line 836 IN quantified predicates are never executed directly. They are rather wrapped inside nodes called IN Optimizers (Item_in_optimizer) which take care of the execution. However, this is not done during query preparation. Unfortunately the LIKE predicate pre-evaluates constant right-hand side arguments even during name resolution. Likely this is meant as an optimization. Fixed by not pre-evaluating LIKE arguments in view prepare mode.
-
Sunny Bains authored
Handle overflow when reading value from SELECT MAX(C) FROM T; Call ha_innobase::info() after initializing the autoinc value in ha_innobase::open(). Fix for both the builtin and plugin. rb://402
-
Sunny Bains authored
The bug is due to a double delete of a BLOB, once via: rollback -> btr_cur_pessimistic_delete() and the second time via purge. The bug is in row_upd_clust_rec_by_insert(). There we relinquish ownership of the non-updated BLOB columns in btr_cur_mark_extern_inherited_fields() before building the row entry that will be inserted and whose contents will be logged in the UNDO log. However, we don't set the BLOB column later to INHERITED so that a possible rollback will not free the original row's non-updated BLOB entries. This is because the condition that checks for that is in : if (node->upd_ext) {}. node->upd_ext is non-NULL only if a BLOB column was updated and that column is part of some key ordering (see row_upd_replace()). This results in the non-update BLOB columns being deleted during a rollback and subsequently by purge again. rb://413
-
- 04 Aug, 2010 5 commits
-
-
Georgi Kodinov authored
Reverted the ulong->uint diff Re-applied the first diff. The original commit message follows: enum plugin system variables are ulong internally, not int. On systems where long is not the same as an int it causes problems. Fixed by correct typecasting. Removed the test from the experimental list.
-
Jimmy Yang authored
rb://399 approved by Sunny Bains
-
Bjorn Munch authored
-
Jimmy Yang authored
foreign keys at once rb://391 approved by Heikki Z
-
Bjorn Munch authored
Follow-up patch: added test cases for -0 and while
-
- 03 Aug, 2010 6 commits
-
-
unknown authored
-
Georgi Kodinov authored
The enum system variables were handled inconsistently as ints, unsigned int and unsigned long on various places. This caused problems on platforms on which sizeof(int) != sizeof(long). Fixed by homogenizing the type of the enum variables to unsigned int, since it's size compatible with the C enum type. Removed the test from the experimental list.
-
Bjorn Munch authored
if() treated any non-numeric string as false Fixed to treat those as true instead Added some test cases Fixed missing $ in variable name in include/mix2.inc
-
Alfranio Correia authored
-
unknown authored
Post fix mysql-test/t/mysqlbinlog.test: Updated for Bug#34283
-
unknown authored
With statement- or mixed-mode logging, "LOAD DATA INFILE" queries are written to the binlog using special types of log events. When mysqlbinlog reads such events, it re-creates the file in a temporary directory with a generated filename and outputs a "LOAD DATA INFILE" query where the filename is replaced by the generated file. The temporary file is not deleted by mysqlbinlog after termination. To fix the problem, in mixed mode we go to row-based. In SBR, we document it to remind user the tmpfile is left in a temporary directory. mysql-test/extra/rpl_tests/rpl_loaddata.test: Updated for Bug#34283 mysql-test/suite/binlog/r/binlog_mixed_load_data.result: Test result for BUG#34283. mysql-test/suite/binlog/t/binlog_killed_simulate.test: Updated for Bug#34283 mysql-test/suite/binlog/t/binlog_mixed_load_data.test: Added the test file to verify that 'load data infile...' statement will go to row-based in mixed mode. mysql-test/suite/binlog/t/binlog_stm_blackhole.test: Updated for Bug#34283 mysql-test/suite/rpl/r/rpl_innodb_mixed_dml.result: Updated for Bug#34283 mysql-test/suite/rpl/t/rpl_loaddata_fatal.test: Updated for Bug#34283 mysql-test/suite/rpl/t/rpl_loaddata_map.test: Updated for Bug#34283 mysql-test/suite/rpl/t/rpl_slave_load_remove_tmpfile.test: Updated for Bug#34283 mysql-test/suite/rpl/t/rpl_stm_log.test: Updated for Bug#34283 sql/sql_load.cc: Added code to go to row-based in mixed mode for 'load data infile ...' statement
-