- 10 Dec, 2009 3 commits
-
-
He Zhenxing authored
-
He Zhenxing authored
-
He Zhenxing authored
mysql-test/include/kill_query.inc: Error 1034 can be generated when change MyISAM table indexes was interrupted mysql-test/r/rpl_killed_ddl.result: table t4 may not exists because the ALTER above was interrupted mysql-test/t/rpl_killed_ddl.test: table t4 may not exists because the ALTER above was interrupted
-
- 09 Dec, 2009 6 commits
-
-
Alfranio Correia authored
-
Olav Sandstaa authored
This fix has been proposed by Sergey Petrunya and has been contributed under SCA by sca@askmonty.org. The cause for this valgrind error is that in the function add_cond_and_fix() in sql_select.cc an Item_cond_and object is created. This is marked as fixed but does not have a correct table_map() attribute. Later, in make_join_select(), if engine_condition_pushdown is in use, this table map is used and results in the valgrind error. The fix is to add a call to update_used_tables() in add_cond_and_fix() so that the table map is updated correctly. This patch is tested by multiple existing tests (e.g. the tests innodb_mysql, innodb, fulltext, compress all produces this valgrind warning/error without this fix). sql/sql_select.cc: In add_cond_and_fix() add a call to update_used_tables() to ensure the table map is updated.
-
He Zhenxing authored
-
He Zhenxing authored
-
He Zhenxing authored
-
He Zhenxing authored
There are three issues that caused rpl_killed_ddl fails sporadically in pb2: 1) thd->clear_error() was not called before create Query event if operation is executed successfully. 2) DATABASE d2 might do exist because the statement to CREATE or ALTER it was killed 3) because of bug 43353, kill the query that do DROP FUNCTION or DROP PROCEDURE can result in SP not found This patch fixed all above issues by: 1) Called thd->clear_error() if the operation succeeded. 2) Add IF EXISTS to the DROP DATABASE d2 statement 3) Temporarily disabled testing DROP FUNCTION/PROCEDURE IF EXISTS. mysql-test/t/rpl_killed_ddl.test: DATABASE d2 might not exists, add IF EXITS to the DROP statement sql/sql_db.cc: Called thd->clear_error() if the operation succeeded
-
- 08 Dec, 2009 1 commit
-
-
Alfranio Correia authored
Disabled execution in valgrind to avoid false positive memory leaks due to fault-injection tests (i.e. call to abort()).
-
- 07 Dec, 2009 1 commit
-
-
Luis Soares authored
-
- 06 Dec, 2009 5 commits
-
-
Luis Soares authored
Removed rpl_cross_version from experimental list.
-
Luis Soares authored
-
Luis Soares authored
{PROCEDURE|FUNCTION} FROM ...' The master would hit an assertion when binary log was active. This was due to the fact that the thread's diagnostics area was being cleared before writing to the binlog, independently of mysql_routine_grant returning an error or not. When mysql_routine_grant was to return an error, the return value and the diagnostics area contents would mismatch. Consequently, neither my_ok would be called nor an error would be signaled in the diagnostics area, eventually triggering the assertion in net_end_statement. We fix this by not clearing the diagnostics area at binlogging time.
-
Staale Smedseng authored
-
Staale Smedseng authored
solaris after a crash This patch adds a Solaris-specific version of print_stacktrace() which uses printstack(2), available on all Solaris versions since Solaris 9. (While Solaris 11 adds support for the glibc functions backtrace_*() as of PSARC/2007/162, printstack() is used for consistency over all Solaris versions.) The symbol names are mangled, so use of c++filt may be required as described in the MySQL documentation. sql/stacktrace.c: Added Solaris-specific print_stacktrace().
-
- 05 Dec, 2009 1 commit
-
-
Alfranio Correia authored
-
- 04 Dec, 2009 3 commits
-
-
Davi Arnaut authored
The problem was that the multiple evaluations of a ENCODE or DECODE function within a single statement caused the random generator to be reinitialized at each evaluation, even though the parameters were constants. The solution is to initialize the random generator only once if the password (seed) parameter is constant. This patch borrows code and ideas from Georgi Kodinov's patch. mysql-test/r/func_str.result: Add test case result. mysql-test/r/ps.result: Add test case result. mysql-test/t/func_str.test: Add test case for Bug#49141 mysql-test/t/ps.test: Add test case for Bug#49141 sql/item_strfunc.cc: Move seed generation code to a separate method. Seed only once if the password (seed) argument is constant. Remove duplicated code and use a transform method to apply encoding or decoding. sql/item_strfunc.h: Add parameter to signal whether the PRNG is already seeded. Introduce transform method. Combine val_str methods. sql/sql_crypt.cc: Remove method. sql/sql_crypt.h: Seed is supplied as two long integers.
-
Davi Arnaut authored
Post-merge fix: Redirect stderr to a file as to avoid buffering problems due to redirecting stderr to stdout. mysql-test/r/mysql_upgrade.result: Update test case result. mysql-test/t/mysql_upgrade.test: Redirect stderr to a file, cat and remove.
-
Alfranio Correia authored
This patch fixes three bugs as follows. First, aborting the server while purging binary logs might generate orphan files due to how the purge operation was implemented: (purge routine - sql/log.cc - MYSQL_BIN_LOG::purge_logs) 1 - register the files to be removed in a temporary buffer. 2 - update the log-bin.index. 3 - flush the log-bin.index. 4 - erase the files whose names where register in the temporary buffer in step 1. Thus a failure while executing step 4 would generate an orphan file. Second, a similar issue might happen while creating a new binary as follows: (create routine - sql/log.cc - MYSQL_BIN_LOG::open) 1 - open the new log-bin. 2 - update the log-bin.index. Thus a failure while executing step 1 would generate an orphan file. To fix these issues, we record the files to be purged or created before really removing or adding them. So if a failure happens such records can be used to automatically remove dangling files. The new steps might be outlined as follows: (purge routine - sql/log.cc - MYSQL_BIN_LOG::purge_logs) 1 - register the files to be removed in the log-bin.~rec~ placed in the data directory. 2 - update the log-bin.index. 3 - flush the log-bin.index. 4 - delete the log-bin.~rec~. (create routine - sql/log.cc - MYSQL_BIN_LOG::open) 1 - register the file to be created in the log-bin.~rec~ placed in the data directory. 2 - open the new log-bin. 3 - update the log-bin.index. 4 - delete the log-bin.~rec~. (recovery routine - sql/log.cc - MYSQL_BIN_LOG::open_index_file) 1 - open the log-bin.index. 2 - open the log-bin.~rec~. 3 - for each file in log-bin.~rec~. 3.1 Check if the file is in the log-bin.index and if so ignore it. 3.2 Otherwise, delete it. The third issue can be described as follows. The purge operation was allowing to remove a file in use thus leading to the loss of data and possible inconsistencies between the master and slave. Roughly, the routine was only taking into account the dump threads and so if a slave was not connect the file might be delete even though it was in use.
-
- 03 Dec, 2009 7 commits
-
-
Gleb Shchepa authored
After-push minor code cleanup for WL 2360: unnecessary external reference to LOCK_thread_count has been removed from ha_innodb.cc.
-
unknown authored
"mysql_upgrade (ver 5.1) add 3 fields to mysql.proc table but does not set values". mysql_upgrade (ver 5.1) adds 3 fields (character_set_client, collation_connection and db_collation) to the mysql.proc table, but does not set any values. When we run stored procedures, which were created with mysql 5.0, a warning is logged into the error log. The solution to this is for mysql_upgrade to set default best guess values for these fields. A warning is also written during upgrade, to make the user aware that default values are set. client/mysql_upgrade.c: Result lines which start with "WARNING" are passed through to the output. This way we have a way of triggering WARNING-messages during upgrade directly from the .sql-script. mysql-test/r/mysql_upgrade.result: Expected result of the test. mysql-test/t/mysql_upgrade.test: Added a test-case for the bug. scripts/mysql_system_tables_fix.sql: The new fields are populated, and warnings are written.
-
Evgeny Potemkin authored
-
Evgeny Potemkin authored
-
Evgeny Potemkin authored
Test case cleanup. mysql-test/r/ps.result: Test case cleanup for bug#48508. mysql-test/t/ps.test: Test case cleanup for bug#48508.
-
Georgi Kodinov authored
When checking for an error after removing the special view error handler the code was not taking into account that open_tables() may fail because of the current statement being killed. Added a check for thd->killed. Added a client program to test it.
-
Alexander Barkov authored
Problem: Item_char_typecast reported wrong max_length when casting to BINARY, which lead, in particular, in wrong "ORDER BY BINARY(char_column)" results. Fix: making Item_char_typecast report correct max_length. @ mysql-test/r/ctype_utf16.result Fixing old incorrect test result. @ mysql-test/r/ctype_utf32.result Fixing old incorrect test result. @ mysql-test/r/ctype_utf8.result Adding new test @ mysql-test/t/ctype_utf8.test Adding new test @ sql/item_timefunc.cc Making Item_char_typecast report correct max_length when cast is done to BINARY.
-
- 02 Dec, 2009 3 commits
-
-
Evgeny Potemkin authored
-
Evgeny Potemkin authored
-
Alexander Barkov authored
Problem: SHOW CREATE FUNCTION and SELECT DTD_IDENTIFIER FROM I_S.ROUTINES returned wrong values in case of ENUM return data type and UCS2 character set. Fix: the string to collect returned data type was incorrectly set to "binary" character set, therefore UCS2 values where returned with extra '\0' characters. Setting string character set to creation_ctx->get_client_cs() in sp_find_routine(), and to system_charset_info in sp_create_routine fixes the problem. Adding tests: - the original test with Latin letters - an extra test with non-Latin letters
-
- 01 Dec, 2009 9 commits
-
-
Evgeny Potemkin authored
Actually there is two different bugs. The first one caused crash on queries with WHERE condition over views containing WHERE condition. A wrong check for prepared statement phase led to items for view fields being allocated in the execution memory and freed at the end of execution. Thus the optimized WHERE condition refers to unallocated memory on the second execution and server crashed. The second one caused by the Item_cond::compile function not saving changes it made to the item tree. Thus on the next execution changes weren't reverted and server crashed on dereferencing of unallocated space. The new helper function called is_stmt_prepare_or_first_stmt_execute is added to the Query_arena class. The find_field_in_view function now uses is_stmt_prepare_or_first_stmt_execute() to check whether newly created view items should be freed at the end of the query execution. The Item_cond::compile function now saves changes it makes to item tree. mysql-test/r/ps.result: Added a test case for the bug#48508. mysql-test/t/ps.test: Added a test case for the bug#48508. sql/item_cmpfunc.cc: Bug#48508: Crash on prepared statement re-execution. The Item_cond::compile function now saves changes it makes to item tree. sql/sql_base.cc: Bug#48508: Crash on prepared statement re-execution. The find_field_in_view function now uses is_stmt_prepare_or_first_stmt_execute() to check whether newly created view items should be freed at the end of the query execution. sql/sql_class.h: Bug#48508: Crash on prepared statement re-execution. The Query_arena::is_stmt_prepare_or_first_sp_execute function now correctly do its check.
-
Satya B authored
-
Satya B authored
the last IF ELSE part which decides the plugin name is not relevant as we still have to substitute the occurences of INNOBASE with INNODB_PLUGIN. Remove the last IF ELSE part in CMakeLists.txt as it doesn't make sense in 5.1.
-
Gleb Shchepa authored
manual merge 5.0-->5.1, updating InnoDB plugin.
-
Gleb Shchepa authored
The bug 38816 changed the lock that protects THD::query from LOCK_thread_count to LOCK_thd_data, but didn't update the associated InnoDB functions. 1. The innobase_mysql_prepare_print_arbitrary_thd and the innobase_mysql_end_print_arbitrary_thd InnoDB functions have been removed, since now we have a per-thread mutex: now we don't need to wrap several inter-thread access tries to THD::query with a single global LOCK_thread_count lock, so we can simplify the code. 2. The innobase_mysql_print_thd function has been modified to lock LOCK_thd_data in direct way.
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
unknown authored
and rpl.rpl_get_master_version_and_clock.
-
- 30 Nov, 2009 1 commit
-
-
Satya B authored
-