- 18 May, 2011 3 commits
-
-
Mayank Prasad authored
-
Sergey Glukhov authored
-
Sergey Glukhov authored
There are two problems: 1. There is a missing check for 'year' parameter(year can not be greater than 9999) in makedate function. fix: added check that year can not be greater than 9999. 2. There is a missing check for zero date in from_days() function. fix: added zero date check into Item_func_from_days::get_date() function. mysql-test/r/func_time.result: test case mysql-test/t/func_time.test: test case sql/item_timefunc.cc: --added check that year can not be greater than 9999 for makedate() function --added zero date check into Item_func_from_days::get_date() function
-
- 16 May, 2011 6 commits
-
-
Marc Alff authored
-
Marc Alff authored
-
Kent Boortz authored
- Added an alterantive search path for WiX components - Added a custom welcome dialog to include the copyright line (Bug#59805 and Bug#59512) - Excluded some binaries to make package smaller, in effect makig the "essentials" package obsolete - Added a bit more error checking when running the WiX tools WiX XML changes done by Johannes Taxacher
-
Andrei Elkin authored
notifying PB2 the test fails through mysql-test/collections/default.experimental.
-
Alexander Nozdrin authored
-
Alexander Nozdrin authored
FREED IN FLUSH_READ_LOCK (VALGRIND WARNING). The problem was that under some circustances the memory allocated for Query_tables_list::sroutines was not freed properly. The cause of this problem was the absence of LEX::restore_backup_query_tables_list() call in one of the branches in mysql_table_grant() function.
-
- 14 May, 2011 2 commits
-
-
Vinay Fisrekar authored
-
Vinay Fisrekar authored
Impementing Test Review Comment. Bug test scenario: SELECT is not returning result set for "equal" (=) and "NULL safe equal operator" (<=>) on BIT data type. Extending this scenario for all data types
-
- 13 May, 2011 5 commits
-
-
Marc Alff authored
Before this fix, a thread instrumented for the performance schema, that would perform file io operations, could crash inside the LF_HASH implementation, in cases when my_thread_init is not called. The crash itself has not been reported in 5.5 but similar crashes have been found in 5.6-based development branches, using LF_HASH for more instrumentation. The possibility of a crash in 5.5 is confirmed by code analysis. The problem is that, when my_thread_init() is not called, which can happen for threads in storage engines or thirs party code, my_thread_var is NULL. Using my_thread_var->stacks_ends_here in mysys/lf_alloc-pin.c is unsafe. Given that my_thread_var is used: - only for stacks_ends_here - only on platform with HAVE_ALLOCA - only when there is enough room on the stack and given that the LF_HASH implementation has a fallback algorythm implemented already when using alloca is not possible, using my_thread_var->stacks_ends_here is in fact not a strict requirement, and can be relaxed. The fix is to: - test explicitly if my_thread_var is NULL, to account for cases when my_thread_init() is not used by the calling thread. - not use alloca in this case, and rely on the fall back code already in place. so that the LF_HASH can be supported even without my_thread_init(). The implementation of mysys/lf_alloc-pin.c has been fixed to support this new usage. The units tests in unittest/mysys/lf-t.c have been adjusted accordingly.
-
Bjorn Munch authored
-
Bjorn Munch authored
-
Bjorn Munch authored
-
MySQL Build Team authored
-
- 12 May, 2011 14 commits
-
-
unknown authored
This patch inserts an 'ENABLE_GCOV' option for enabling gcov compilation on Linux machines. It modifies the CMakeLists.txt setting this option to 'OFF' by default. Note: The option requires a debug build. For example, -DCMAKE_BUILD_TYPE:string="Debug"
-
Bjorn Munch authored
-
Bjorn Munch authored
-
Bjorn Munch authored
-
Jon Olav Hauglid authored
This assert could be triggered during two phase commit if binary log was used as transaction coordinator log. The triggered assert checks that the same number of transaction IDs are processed in the prepare and commit phases. The reason it was triggered, was that the transaction consisted of an INSERT/UPDATE IGNORE that had an ignorable error. Since it had an error, no row log events were made and therefore prepared_xids was 0. However, since it was an IGNORE statement, the statement started a read/write statement transaction, committed it and completed successfully. This patch fixes the problem by adjusting the assert to take this possibility into account. Test case added to binlog.binlog_innodb_row.test.
-
Tatjana Azundris Nuernberg authored
-
Bjorn Munch authored
-
Tatjana Azundris Nuernberg authored
-
Tatjana Azundris Nuernberg authored
-
Tatjana Azundris Nuernberg authored
If LOAD DATA INFILE featured a SET clause, the name=value pairs would be regenerated using item::print. Unfortunately, that code is mostly optimized for EXPLAIN EXTENDED output and such, and can not be relied on to return valid SQL. We now name each value its original, user-supplied form and use that to create LOAD DATA INFILE statements for statement-based replication. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: minor change in syntactic sugar mysql-test/suite/rpl/r/rpl_loaddatalocal.result: add test case mysql-test/suite/rpl/t/rpl_loaddatalocal.test: add test case sql/sql_load.cc: Do not try to item::print values in LOAD DATA INFILE's SET clause; they might not even be valid SQL at this point. Use our saved version instead. sql/sql_yacc.yy: If LOAD DATA INFILE has SET name=val clauses, tag the individual val-parts with the user's version so we can later replicate that, rather than the smashed pieces we'd get from item::print once the optimizer's through with our poor values.
-
Tatjana Azundris Nuernberg authored
-
Tatjana Azundris Nuernberg authored
-
Tatjana Azundris Nuernberg authored
-
Tatjana Azundris Nuernberg authored
-
- 11 May, 2011 7 commits
-
-
Luis Soares authored
Automerged bzr bundle from bug report into latest mysql-5.5.
-
Magnus Blåudd authored
-
Alexander Nozdrin authored
-
Georgi Kodinov authored
-
MySQL Build Team authored
increase the version number by two
-
Georgi Kodinov authored
and innodb The 5.5 version of the patch. The server doesn't restrict the data that can be inserted into integer columns with explicitly specified length that's smaller than what the type can handle, e.g. 1234 can be inserted into an INT(2) column just fine. Thus, when calcualting the maximum width of expressions involving such restricted integer columns we need to use the implicit maximum width of the field instead of the explicitly speficied one. Fixed the server to use the implicit maximum in such cases and made sure the implicit maximum is addjusted the same way as the explicit one wrt signedness. Fixed several test case results (ctype_*.result, metadata.result and type_ranges.result) to reflect the extended column widths. Added a regression test case in distinct.test. Note : this is the behavior preserving fix that makes 5.5 behave as 5.1 and earlier. In the mysql trunk we'll add a insert time check for the explict maximum size.
-
Magnus Blåudd authored
- add support for choosing the engine of test table(t1) with $engine_type - add primary key to the test table(t1) to support replication of BLOB/TEXT (also with ENGINE=ndb) - change the suppression since the warning printed to error log now says "Column 1"
-
- 10 May, 2011 3 commits
-
-
Serge Kozlov authored
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-