- 15 Jan, 2010 1 commit
-
-
Georgi Kodinov authored
Added not_embedded to the new dbug_sync test file.
-
- 14 Jan, 2010 1 commit
-
-
Georgi Kodinov authored
-
- 13 Jan, 2010 11 commits
-
-
Martin Hansson authored
-
Ramil Kalimullin authored
-
Ramil Kalimullin authored
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Joerg Bruehe authored
-
Georgi Kodinov authored
-
Ramil Kalimullin authored
-
Sven Sandberg authored
Problem: When RAND() is binlogged in statement mode, the seed is binlogged too, so the replication slave generates the same sequence of random numbers. This makes replication work in many cases, but not in all cases: the order of rows is not guaranteed for, e.g., UPDATE or INSERT...SELECT statements, so the row data will be different if master and slave retrieve the rows in different orders. Fix: Mark RAND() as unsafe. It will generate a warning if binlog_format=STATEMENT and switch to row-logging if binlog_format=ROW. mysql-test/extra/rpl_tests/rpl_row_func003.test: updated test case to ignore new warnings mysql-test/suite/binlog/r/binlog_unsafe.result: updated result file mysql-test/suite/binlog/t/binlog_unsafe.test: Added test for RAND(). Also clarified some old comments. mysql-test/suite/rpl/r/rpl_misc_functions.result: updated result file mysql-test/suite/rpl/r/rpl_nondeterministic_functions.result: updated test case to ignore new warnings mysql-test/suite/rpl/r/rpl_optimize.result: updated result file mysql-test/suite/rpl/r/rpl_row_func003.result: updated result file mysql-test/suite/rpl/t/rpl_misc_functions.test: updated test case to ignore new warnings mysql-test/suite/rpl/t/rpl_nondeterministic_functions.test: updated test case to ignore new warnings mysql-test/suite/rpl/t/rpl_optimize.test: updated test case to ignore new warnings mysql-test/suite/rpl/t/rpl_trigger.test: updated test case to ignore new warnings mysql-test/suite/rpl_ndb/r/rpl_ndb_func003.result: updated result file sql/item_create.cc: Mark RAND() unsafe.
-
Ramil Kalimullin authored
Problem: copying issuer's (or subject's) name tags into an internal buffer from incoming stream we didn't check the buffer overflow. That may lead to memory overrun, crash etc. Fix: ensure we don't overrun the buffer. Note: there's no simple test case (exploit needed). extra/yassl/taocrypt/include/asn.hpp: Fix for bug#50227: Pre-auth buffer-overflow in mySQL through yaSSL - CertDecoder::AddTag() introduced. extra/yassl/taocrypt/src/asn.cpp: Fix for bug#50227: Pre-auth buffer-overflow in mySQL through yaSSL - copying data from incoming stream to the issuer_ or subject_ buffers ensure we don't overrun them. - code cleanup.
-
Gleb Shchepa authored
Selecting of the CONCAT_WS(...<PS parameter>...) result into a user variable may return wrong data. Item_func_concat_ws::val_str contains a number of memory allocation-saving optimization tricks. After the fix for bug 46815 the control flow has been changed to a branch that is commented as "This is quite uncommon!": one of places where we are trying to concatenate strings inplace. However, that "uncommon" place didn't care about PS parameters, that have another trick in Item_sp_variable::val_str(): they use the intermediate Item_sp_variable::str_value field, where they may store a reference to an external argument's buffer. The Item_func_concat_ws::val_str function has been modified to take into account val_str functions (such as Item_sp_variable::val_str) that return a pointer to an internal Item member variable that may reference to a buffer provided. mysql-test/r/func_concat.result: Added test case for bug #50096. mysql-test/t/func_concat.test: Added test case for bug #50096. sql/item_strfunc.cc: Bug #50096: CONCAT_WS inside procedure returning wrong data The Item_func_concat_ws::val_str function has been modified to take into account val_str functions (such as Item_sp_variable::val_str) that return a pointer to an internal Item member variable that may reference to a buffer provided.
-
- 12 Jan, 2010 4 commits
-
-
Martin Hansson authored
MySQL handles the join syntax "JOIN ... USING( field1, ... )" and natural joins by building the same parse tree as a corresponding join with an "ON t1.field1 = t2.field1 ..." expression would produce. This parse tree was not cleaned up properly in the following scenario. If a thread tries to lock some tables and finds that the tables were dropped and re-created while waiting for the lock, it cleans up column references in the statement by means a per-statement free list. But if the statement was part of a stored procedure, column references on the stored procedure's free list weren't cleaned up and thus contained pointers to freed objects. Fixed by adding a call to clean up the current prepared statement's free list. mysql-test/r/sp_sync.result: Bug#48157: Test case mysql-test/t/sp_sync.test: Bug#48157: Test result sql/item.h: Bug#48157: Commented field. sql/sql_parse.cc: Bug#48157: Commented function. sql/sql_update.cc: Bug#48157: fix
-
Joerg Bruehe authored
This includes "MYSQL_U_SCORE_VERSION" in "configure.in".
-
Joerg Bruehe authored
- "release" starts from 1 - "level" ("m2", "rc", ...) is included in the RPM version.
-
Joerg Bruehe authored
but don't take the "tree name" change.
-
- 11 Jan, 2010 3 commits
-
-
Joerg Bruehe authored
- "release" starts from 1 - "level" ("m2", "rc", ...) is included in the RPM version.
-
Gleb Shchepa authored
-
Gleb Shchepa authored
32bit builds with the --enable-assembler flag (enabled by default) fail with an error message: undefined reference to `strmov_overlapp'. Since the fix for bug 48866 we use a home-grown strmov function instead of the ctpcpy function, but the source file for this function was missed in the Makefile.am. The strings/Makefile.am file has been modified to include strmov.c file into ASSEMBLER_x86 and ASSEMBLER_sparc32 sections. strings/Makefile.am: Bug #49955: ld error message: undefined reference to `strmov_overlapp' The strings/Makefile.am file has been modified to include strmov.c file into ASSEMBLER_x86 and ASSEMBLER_sparc32 sections.
-
- 08 Jan, 2010 2 commits
-
-
unknown authored
Recover the right contents of the index file at the end of the test case.
-
unknown authored
Manually deleteing one or more entries from 'master-bin.index', will cause master infinitely loop to send one binlog file. When starting a dump session, master opens index file and search the binlog file which is being requested by the slave. The position of the binlog file in the index file is recorded. it will be used to find the next binlog file when current binlog file has dumped completely. As only the position is used, it may not get the correct file if some entries has been removed manually from the index file. the master will reopen the current binlog file which has been dump completely and redump it if it can not get the next binlog file's name from index file. It obviously is a logical error. Even though it is allowed to manually change index file, but it is not recommended. so after this patch, master sends a fatal error to slave and close the dump session if a new binlog file has been generated and master can not get it from the index file.
-
- 07 Jan, 2010 1 commit
-
-
Luis Soares authored
-
- 06 Jan, 2010 5 commits
-
-
Georgi Kodinov authored
-
unknown authored
Fixed valgrind failure on PB2. sql/log_event.cc: Added code to fix valgrind failure on PB2.
-
unknown authored
Fixed valgrind failure on PB2. sql/log_event.cc: Added code to fix valgrind failure on PB2.
-
unknown authored
Fixed valgrind failure on PB2. sql/log_event.cc: Added code to fix valgrind failure on PB2.
-
unknown authored
Fixed valgrind failure on PB2. sql/log_event.cc: Added code to fix valgrind failure on PB2.
-
- 05 Jan, 2010 1 commit
-
-
He Zhenxing authored
This bug is the same problem as Bug 49836 for 5.1 versions. mysql-test/suite/rpl/r/rpl_geometry.result: Test case for bug 48776 mysql-test/suite/rpl/t/rpl_geometry.test: Test case for bug 48776 sql/rpl_utility.h: Add missing case MYSQL_TYPE_GEOMETRY
-
- 31 Dec, 2009 2 commits
-
-
unknown authored
In statement-based or mixed-mode replication, use DROP TEMPORARY TABLE to drop multiple tables causes different errors on master and slave, when one or more of these tables do not exist. Because when executed on slave, it would automatically add IF EXISTS to the query to ignore all ER_BAD_TABLE_ERROR errors. To fix the problem, do not add IF EXISTS when executing DROP TEMPORARY TABLE on the slave, and clear the ER_BAD_TABLE_ERROR error after execution if the query does not expect any errors. mysql-test/suite/rpl/r/rpl_drop_temp.result: Updated for the patch of bug#49137. mysql-test/suite/rpl/t/rpl_drop_temp.test: Added the test file to verify if DROP MULTI TEMPORARY TABLE will cause different errors on master and slave, when one or more of these tables do not exist. sql/log_event.cc: Added code to handle above cases which are removed from sql_parse.cc sql/sql_parse.cc: Remove the code to issue the 'Unknown table' error, if the temporary table does not exist when dropping it on slave. The above cases decribed in comments will be handled later in log_event.cc.
-
unknown authored
In statement-based or mixed-mode replication, use DROP TEMPORARY TABLE to drop multiple tables causes different errors on master and slave, when one or more of these tables do not exist. Because when executed on slave, it would automatically add IF EXISTS to the query to ignore all ER_BAD_TABLE_ERROR errors. To fix the problem, do not add IF EXISTS when executing DROP TEMPORARY TABLE on the slave, and clear the ER_BAD_TABLE_ERROR error after execution if the query does not expect any errors. mysql-test/r/rpl_drop_temp.result: Updated for the patch of bug#49137. mysql-test/t/rpl_drop_temp.test: Added the test file to verify if DROP MULTI TEMPORARY TABLE will cause different errors on master and slave, when one or more of these tables do not exist. sql/log_event.cc: Added code to handle above cases which are removed from sql_parse.cc sql/sql_parse.cc: Remove the code to issue the 'Unknown table' error, if the temporary table does not exist when dropping it on slave. The above cases decribed in comments will be handled later in log_event.cc.
-
- 30 Dec, 2009 2 commits
-
-
Kent Boortz authored
-
Kent Boortz authored
-
- 26 Dec, 2009 2 commits
-
-
Ramil Kalimullin authored
-
Ramil Kalimullin authored
-
- 24 Dec, 2009 2 commits
-
-
Luis Soares authored
-
Luis Soares authored
to make the test run gracefully on windows. There was also a syntax error in windows part of the test.
-
- 22 Dec, 2009 1 commit
-
-
Georgi Kodinov authored
Several problems fixed : 1. Non constant expressions in UNION ... ORDER BY were not correctly cleaned up in st_select_lex_unit::cleanup() causing crashes in EXPLAIN EXTENDED because of fields quoted by these expressions pointing to the already freed temporary table used to calculate the UNION. Fixed by correctly cleaning up expressions of any depth. 2. Subqueries in the order by part of UNION ... ORDER BY ... caused a crash in EXPLAIN EXTENDED because of a transformation attempt made during EXPLAIN EXTENDED execution. Fixed by not doing the transformation when in EXPLAIN. 3. Fulltext functions caused crash when in the ORDER BY part of an un-parenthesized UNION that gets "promoted" to be valid for the whole union, e.g. SELECT * FROM t1 UNION SELECT * FROM t2 ORDER BY MATCHES (a) AGAINST ('abc' IN BOOLEAN MODE). This is a case that demonstrates a more general problem of parts of the query being moved to another level. When doing such transformation late in the optimization run when most of the flags about the contents of the query are already aggregated it's possible to "split" the flags so that they correctly reflect the new queries after the transformation. In specific the ST_SELECT_LEX::ftfunc_list is holding all the free text function for all the parts of the second SELECT in the UNION and we don't know what part of that is in the ORDER BY that we're to move to the UNION level and what part is about the other parts of the second SELECT. Fixed by throwing and error when such statements are about to be processed by adding a check for the presence of MATCH() inside the ORDER BY clause that's going to get promoted to UNION. To workaround this new limitation one must parenthesize the UNION SELECTs and provide a real global ORDER BY for the UNION outside of the parenthesis.
-
- 24 Dec, 2009 1 commit
-
-
Georgi Kodinov authored
-
- 22 Dec, 2009 1 commit
-
-
Ramil Kalimullin authored
on re-execution of prepared statement Problem: some (see eq_ref_table()) ORDER BY/GROUP BY optimization is called before each PS execution. However, we don't properly initialize its stucture every time before the call. Fix: properly initialize the sturture used. mysql-test/r/ps.result: Fix for bug#49570: Assertion failed: !(order->used & map) on re-execution of prepared statement - test result. mysql-test/t/ps.test: Fix for bug#49570: Assertion failed: !(order->used & map) on re-execution of prepared statement - test case. sql/sql_select.cc: Fix for bug#49570: Assertion failed: !(order->used & map) on re-execution of prepared statement - set order->used to 0 before each eq_ref_table() call, as the function relies on that.
-