- 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 4 commits
-
-
Serge Kozlov authored
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Luis Soares authored
IN WAIT_SHOW_CONDITION) There was a typo in the name of one of the parameters to the include file wait_show_condition. The parameter name was being set to "connection" instead of "condition". We fix this typo, improve one instruction in the test case and deploy parameter checks inside wait_show_condition.inc.
-
- 09 May, 2011 4 commits
-
-
Serge Kozlov authored
-
Serge Kozlov authored
Replaced the error code by error name
-
Bjorn Munch authored
Added --result-file option, which will produce var/mtr-results.txt Output has a simple format: <tag> : <value> for general info on test run { <tag> : <value> .... } for each test Output from failed tests are included but may be truncated. See WL for more details.
-
Alexander Nozdrin authored
Attempts to assign value to a table column from trigger by using NEW.column_name pseudo-variable might result in garbled data. That happened when: - the column had a BLOB-based type (e.g. TEXT) and - the value being assigned was retrieved from stored routine variable of the same type. The problem was that BLOB values were not copied correctly in this case. Instead of doing a copy of a real value, the value's representation in record buffer was copied. This representation is essentially a pointer to a buffer associated with the virtual table for routine variables where the real value is stored. Since this buffer got freed once trigger was left or could have changed its contents when new value was assigned to corresponding routine variable such a shallow copying resulted in garbled data in NEW.colum_name column. It worked in 5.1 due to a subtle bug in create_virtual_tmp_table(): - in 5.1 create_virtual_tmp_table() returned a table which had db_low_byte_first == false. - in 5.5 and up create_virtual_tmp_table() returns a table which has db_low_byte_first == true. Actually, db_low_byte_first == false only for ISAM storage engine, which was deprecated and removed in 5.0. Having db_low_byte_first == false led to getting false in the complex condition for the 2nd "if" in field_conv(), which in turn led to copy-blob-behavior as a fall-back strategy: - to->table->s->db_low_byte_first was true (correct value) - from->table->s->db_low_byte_first was false (incorrect value) In 5.5 and up that condition is true, which means blob-values are not copied.
-
- 06 May, 2011 6 commits
-
-
Alexander Nozdrin authored
THAT CALL STORED PROCEDURES. The bug was introduced by WL#4435. The problem was that if a stored procedure generated a few result sets with different set of columns, a new memory would be allocated after every EXECUTE for every result set. The fix is to introduce a new memory root in scope of MYSQL_STMT, and to store result-set metadata in that memory root.
-
Alexander Nozdrin authored
(SUBSTRING inside a stored function works too slow). The user-visible problem was that the server started to consume memory if a stored-routine of some sort is executed subsequently. The memory was freed only after the corresponding connection was closed. Technically, the problem was that the memory needed for temporary string conversions was allocated on the connection ("persistent") memory root, instead of statement one. The root cause of this problem was the incorrect patch for Bug 55744. That patch wrongly fixed a crash in prepared-statement-mode introduced by another patch. The patch for Bug 55744 used wrong condition to check if prepared statement mode is active (or whether the connection-scoped or statement-scoped memory root should be used). The thing is that for prepared statements such conversions should be done in the connection memory root, so that that the transformations of item-tree were correctly remembered in the PREPARE-phase. The fix is to use proper condition to detect prepared-statement-mode and use proper memory root.
-
Alexander Nozdrin authored
(SUBSTRING inside a stored function works too slow). Background: - THD classes derives from Query_arena, thus inherits the 'state' attribute and related operations (is_stmt_prepare() & co). - Although these operations are available in THD, they must not be used. THD has its own attribute to point to the active Query_arena -- stmt_arena. - So, instead of using thd->is_stmt_prepare(), thd->stmt_arena->is_stmt_prepare() must be used. This was the root cause of Bug 60025. This patch enforces the proper way of calling those operations. is_stmt_prepare() & co are declared as private operations in THD (thus, they are hidden from being called on THD instance). The patch tries to minimize changes in 5.5.
-
Magnus Blåudd authored
between 5.1 and 5.5, it's purpose is to set the compiler flags in a way that does not optimize away the call stack(i.e don't use any -OX flags at all)
-
Magnus Blåudd authored
-
Sunanda Menon authored
-