- 11 May, 2011 3 commits
-
-
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.
-
- 10 May, 2011 2 commits
-
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
- 09 May, 2011 2 commits
-
-
Serge Kozlov authored
-
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 8 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
-
unknown authored
-
Karen Langford authored
-
- 05 May, 2011 6 commits
-
-
Luis Soares authored
Automerge from mysql-5.1 into mysql-5.5.
-
Luis Soares authored
Automerged bzr bundle from bug report: luis.soares@oracle.com-20110505224815-6ob90n7suxsoizvs.bundle
-
Luis Soares authored
Manual merge from mysql-5.1 into mysql-5.5. Conflicts ========= Text conflict in mysql-test/suite/rpl/t/rpl_row_until.test Text conflict in sql/handler.h Text conflict in storage/archive/ha_archive.cc
-
Luis Soares authored
Fix for all "postion" in Oracle files (s/postion/position). Updated the copyright notices where needed.
-
Luis Soares authored
Automerging cset into latest mysql-5.5.
-
Luis Soares authored
WORK WITH --START-POSITION If setting --start-position to start after the FD event, mysqlbinlog will output an error stating that it has not found an FD event. However, its not that mysqlbinlog does not find it but rather that it does not processes it in the regular way (i.e., it does not print it). Given that one is using --base64-output=DECODE-ROWS then not printing it is actually fine. To fix this, we make mysqlbinlog not to complain when it has not printed the FD event, is outputing in base64, but is decoding the rows.
-
- 04 May, 2011 5 commits
-
-
Luis Soares authored
There are a couple of valgrind warnings in 5.5 codebase, that do not exist in 5.6. The root cause was found and fixed in 5.6 codebase before (BUG#11763880 and BUG#11763879), but the patches were only pushed to 5.6. To fix it in 5.5, we cherrypicked the csets from 5.6 and merged them in 5.5.
-
Alexander Nozdrin authored
-
Luis Soares authored
zhenxing.he@sun.com-20101117085902-n9gfvlkmm44t38y0 This takes care of valgrind warnings in 5.5 that exhibit the same trace as in BUG#11763879 (BUG#56649).
-
Luis Soares authored
zhenxing.he@sun.com-20101202073812-iel8lvhmulyagtsv This takes care of valgrind warnings in 5.5 that exhibit the same trace as in BUG#11763880 (BUG#56650).
-
Alexander Nozdrin authored
The problem was that wrong structure of mysql.event was not detected and the server continued to use wrongly-structured data. The fix is to check the structure of mysql.event after opening before any use. That makes operations with events more strict -- some operations that might work before throw errors now. That seems to be Ok. Another side-effect of the patch is that if mysql.event is corrupted, unrelated DROP DATABASE statements issue an SQL warning about inability to open mysql.event table.
-
- 03 May, 2011 2 commits
-
-
MySQL Build Team authored
-
Kent Boortz authored
-
- 02 May, 2011 5 commits
-
-
Sven Sandberg authored
-
Vasil Dimov authored
-
Vasil Dimov authored
-
Vasil Dimov authored
-
Bjorn Munch authored
-
- 30 Apr, 2011 1 commit
-
-
Nirbhay Choubey authored
-
- 29 Apr, 2011 6 commits
-
-
Davi Arnaut authored
-
Bjorn Munch authored
Make a qualified guess: if $basedir/lib does not exist but $basedir/lib64 does, then the latter is the proper value for $MYSQL_LIBDIR Tested on the RPMS of 5.5.12.
-
Bjorn Munch authored
Added code to look for repetitions and only repeat warnings once Reduced time spent in check-warnings by almost 20% for full test suite
-
Nirbhay Choubey authored
.editrc on linux. MySQL client when build with libedit support ignores .editrc at startup. The reason for this regression was the incluison of a safety check, issetugid(), which is not available on some linux platforms. Fixed by adding an equivalent check for platforms which have get[e][u|g]id() set of functions. cmd-line-utils/libedit/el.c: Bug#11757855 - 49967: built-in libedit doesn't read .editrc on linux. Added function calls to check user/group IDs on linux systems which does not have issetugid() function. configure.in: Bug#11757855 - 49967: built-in libedit doesn't read .editrc on linux. Added check for getuid, geteuid, getgid, getegid functions.
-
Bjorn Munch authored
-
Vasil Dimov authored
(empty, the exact same changes are already in 5.5)
-