- 20 Aug, 2010 3 commits
-
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
- 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.
-
- 13 Aug, 2010 2 commits
-
-
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 3 commits
-
-
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 2 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.
-
- 04 Aug, 2010 3 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.
-
Bjorn Munch authored
-
Bjorn Munch authored
Follow-up patch: added test cases for -0 and while
-
- 03 Aug, 2010 5 commits
-
-
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
-
- 02 Aug, 2010 6 commits
-
-
Alfranio Correia authored
A CREATE...SELECT that fails is written to the binary log if a non-transactional statement is updated. If the logging format is ROW, the CREATE statement and the changes are written to the binary log as distinct events and by consequence the created table is not rolled back in the slave. In this patch, we opted to let the slave goes out of sync by not writting to the binary log the CREATE statement. We do this by simply reseting the binary log's cache. mysql-test/suite/rpl/r/rpl_drop.result: Added a test case. mysql-test/suite/rpl/t/rpl_drop.test: Added a test case. sql/log.cc: Introduced a function to clean up the cache. sql/log.h: Introduced a function to clean up the cache. sql/sql_insert.cc: Cleaned up the binary log cache if a CREATE...SELECT fails.
-
Bjorn Munch authored
The expect file can now include "restart:<server options>" Also drop check-testcase if this has been done Added comment explaining the restart: syntax
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
- 01 Aug, 2010 1 commit
-
-
Gleb Shchepa authored
Queries may crash, if 1) the GREATEST or the LEAST function has a mixed list of numeric and LONGBLOB arguments and 2) the result of such a function goes through an intermediate temporary table. An Item that references a LONGBLOB field has max_length of UINT_MAX32 == (2^32 - 1). The current implementation of GREATEST/LEAST returns REAL result for a mixed list of numeric and string arguments (that contradicts with the current documentation, this contradiction was discussed and it was decided to update the documentation). The max_length of such a function call was calculated as a maximum of argument max_length values (i.e. UINT_MAX32). That max_length value of UINT_MAX32 was used as a length for the intermediate temporary table Field_double to hold GREATEST/LEAST function result. The Field_double::val_str() method call on that field allocates a String value. Since an allocation of String reserves an additional byte for a zero-termination, the size of String buffer was set to (UINT_MAX32 + 1), that caused an integer overflow: actually, an empty buffer of size 0 was allocated. An initialization of the "first" byte of that zero-size buffer with '\0' caused a crash. The Item_func_min_max::fix_length_and_dec() has been modified to calculate max_length for the REAL result like we do it for arithmetical operators. ****** Bug #54461: crash with longblob and union or update with subquery Queries may crash, if 1) the GREATEST or the LEAST function has a mixed list of numeric and LONGBLOB arguments and 2) the result of such a function goes through an intermediate temporary table. An Item that references a LONGBLOB field has max_length of UINT_MAX32 == (2^32 - 1). The current implementation of GREATEST/LEAST returns REAL result for a mixed list of numeric and string arguments (that contradicts with the current documentation, this contradiction was discussed and it was decided to update the documentation). The max_length of such a function call was calculated as a maximum of argument max_length values (i.e. UINT_MAX32). That max_length value of UINT_MAX32 was used as a length for the intermediate temporary table Field_double to hold GREATEST/LEAST function result. The Field_double::val_str() method call on that field allocates a String value. Since an allocation of String reserves an additional byte for a zero-termination, the size of String buffer was set to (UINT_MAX32 + 1), that caused an integer overflow: actually, an empty buffer of size 0 was allocated. An initialization of the "first" byte of that zero-size buffer with '\0' caused a crash. The Item_func_min_max::fix_length_and_dec() has been modified to calculate max_length for the REAL result like we do it for arithmetical operators. mysql-test/r/func_misc.result: Test case for bug #54461. ****** Test case for bug #54461. mysql-test/t/func_misc.test: Test case for bug #54461. ****** Test case for bug #54461. sql/item_func.cc: Bug #54461: crash with longblob and union or update with subquery The Item_func_min_max::fix_length_and_dec() has been modified to calculate max_length for the REAL result like we do it for arithmetical operators. ****** Bug #54461: crash with longblob and union or update with subquery The Item_func_min_max::fix_length_and_dec() has been modified to calculate max_length for the REAL result like we do it for arithmetical operators.
-
- 30 Jul, 2010 7 commits
-
-
Davi Arnaut authored
Fix compiler warnings. mysys/stacktrace.c: Tag unused parameters. sql/sql_lex.cc: Variable becomes unused in non-debug builds. Also, no need to assert the obvious.
-
Luis Soares authored
-
Georgi Kodinov authored
-
Luis Soares authored
mostly because existing test result files were not updated.
-
Georgi Kodinov authored
In order to be able to check if the set of the grouping fields in a GROUP BY has changed (and thus to start a new group) the optimizer caches the current values of these fields in a set of Cached_item derived objects. The Cached_item_str, used for caching varchar and TEXT columns, is limited in length by the max_sort_length variable. A String buffer to store the value with an alloced length of either the max length of the string or the value of max_sort_length (whichever is smaller) in Cached_item_str's constructor. Then, at compare time the value of the string to compare to was truncated to the alloced length of the string buffer inside Cached_item_str. This is all fine and valid, but only if you're not assigning values near or equal to the alloced length of this buffer. Because when assigning values like this the alloced length is rounded up and as a result the next set of data will not match the group buffer, thus leading to wrong results because of the changed alloced_length. Fixed by preserving the original maximum length in the Cached_item_str's constructor and using this instead of the alloced_length to limit the string to compare to. Test case added.
-
Davi Arnaut authored
-
Davi Arnaut authored
Fix a regression (due to a typo) which caused spurious incorrect argument errors for long data stream parameters if all forms of logging were disabled (binary, general and slow logs). sql/sql_prepare.cc: Add a missing logical NOT operator.
-