- 29 Oct, 2009 1 commit
-
-
The 'rpl_get_master_version_and_clock' test verifies if the slave I/O thread tries to reconnect to master when it tries to get the values of the UNIX_TIMESTAMP, SERVER_ID from master under network disconnection. So the master server is restarted for making the transient network disconnection. Restarting master server can bring two problems as following: 1. The time out error is encountered sporadically. The slave I/O thread tries to reconnect master ten times, which is set in my.cnf. So in the test framework sporadically the slave I/O thread really stoped when it can't reconnect to master in the ten times successfully before the master starts, then the time out error will be encountered while waiting for the slave to start. 2. These warnings and errors are produced in server log file when the slave I/O thread tries to get the values of the UNIX_TIMESTAMP, SERVER_ID from master under the transient network disconnection. To fix problem 1, increase the master retry count to sixty times, so that the slave I/O thread has enough time to reconnect master successfully. To fix problem 2, suppress these warnings and errors by mtr suppression, because they are expected.
-
- 28 Oct, 2009 4 commits
-
-
Konstantin Osipov authored
Bug#46539 Various crashes on INSERT IGNORE SELECT + SELECT FOR UPDATE. If a transaction was rolled back inside InnoDB due to a deadlock or lock wait timeout, and the statement had IGNORE clause, the server could crash at the end of the statement or on shutdown. This was caused by the error handling infrastructure's attempt to ignore a non-ignorable error. When a transaction rollback request is raised, switch off current_select->no_error flag, so that the following error won't be ignored. Instead, we could add !thd->is_fatal_sub_stmt_error to my_message_sql(), but since in write_record() we switch off no_error, the same approach is used in thd_mark_transaction_to_rollback(). @todo: call thd_mark_transaction_to_rollback() from handler::print_error(), then we can easily make sure that the error reported by print_error is not ignored.
-
Sergey Glukhov authored
-
Sergey Glukhov authored
test result fix
-
- 27 Oct, 2009 14 commits
-
-
Sergey Vojtovich authored
-
Sergey Vojtovich authored
BUG#47073 - valgrind errs, corruption,failed repair of partition, low myisam_sort_buffer_size Fixed race conditions discovered with the provided test case and stabilized test case.
-
Tatiana A. Nurnberg authored
-
Georgi Kodinov authored
-
Tatiana A. Nurnberg authored
"What do you mean, there's a bug? There isn't even code!" There was some token code for plug-in variables of the SET type, but clearly this never worked, or was subject to massive bit rot since. Bug-fixes ... fail-safes ... tests -- fais au mieux, mon chou!
-
Georgi Kodinov authored
-
Sergey Glukhov authored
-
Sergey Glukhov authored
-
Sergey Glukhov authored
-
Sergey Glukhov authored
-
Tatiana A. Nurnberg authored
-
Sergey Vojtovich authored
-
Sergey Vojtovich authored
BUG#41597 - After rename of user, there are additional grants when grants are reapplied. Fixed build failure on Windows. Added missing cast.
-
Sergey Glukhov authored
Problem 1: column_priv_hash uses utf8_general_ci collation for the key comparison. The key consists of user name, db name and table name. Thus user with privileges on table t1 is able to perform the same operation on T1 (the similar situation with user name & db name, see acl_cache). So collation which is used for column_priv_hash and acl_cache should be case sensitive. The fix: replace system_charset_info with my_charset_utf8_bin for column_priv_hash and acl_cache Problem 2: The same situation with proc_priv_hash, func_priv_hash, the only difference is that Routine name is case insensitive. So the fix is to use my_charset_utf8_bin for proc_priv_hash & func_priv_hash and convert routine name into lower case before writing the element into the hash and before looking up the key. Additional fix: mysql.procs_priv Routine_name field collation is changed to utf8_general_ci. It's necessary for REVOKE command (to find a field by routine hash element values). Note: It's safe for lower-case-table-names mode too because db name & table name are converted into lower case (see GRANT_NAME::GRANT_NAME).
-
- 26 Oct, 2009 1 commit
-
-
Georgi Kodinov authored
-
- 21 Oct, 2009 1 commit
-
-
Georgi Kodinov authored
If the first argument to GeomFromWKB function is a geometry field then the function just returns its value. However in doing so it's not preserving first argument's null_value flag and this causes unexpected null value to be returned to the calling function. Fixed by updating the null_value of the GeomFromWKB function in such cases (and all other cases that return a NULL e.g. because of not enough memory for the return buffer).
-
- 23 Oct, 2009 1 commit
-
-
Ramil Kalimullin authored
Problem: involving a spatial index for "non-spatial" queries (that don't containt MBRXXX() functions) may lead to failed assert. Fix: don't use spatial indexes in such cases.
-
- 21 Oct, 2009 2 commits
-
-
Ramil Kalimullin authored
line 138 when forcing a spatial index Problem: "Spatial indexes can be involved in the search for queries that use a function such as MBRContains() or MBRWithin() in the WHERE clause". Using spatial indexes for JOINs with =, <=> etc. predicates is incorrect. Fix: disable spatial indexes for such queries.
-
Tatiana A. Nurnberg authored
-
- 20 Oct, 2009 4 commits
-
-
Georgi Kodinov authored
Removed the verify callback, as it's not needed to verify even self signed certificates and is a security problem.
-
Satya B authored
-
Satya B authored
grants are reapplied. After renaming a user and trying to re-apply grants results in additional grants. This is because we use username as part of the key for GRANT_TABLE structure. When the user is renamed, we only change the username stored and the hash key still contains the old user name and this results in the extra privileges Fixed by rebuilding the hash key and updating the column_priv_hash structure when the user is renamed
-
Tatiana A. Nurnberg authored
If a thread is killed in the server, we throw "shutdown" only if one is actually in progress; otherwise, we throw "query interrupted". Control-C in the mysql command-line client is "incremental" now. First Control-C sends KILL QUERY (when connected to 5.0+ server, otherwise, see next) Next Control-C sends KILL CONNECTION Next Control-C aborts client. As the first two steps only pertain to an existing query, Control-C will abort the client right away if no query is running. client will give more detailed/consistent feedback on Control-C now.
-
- 19 Oct, 2009 1 commit
-
-
Georgi Kodinov authored
UPDATE + VIEW + SP + MERGE + ALTER When cleaning up the stored procedure's internal structures the flag to ignore the errors for INSERT/UPDATE IGNORE was not cleaned up. As a result error ignoring was on during name resolution. And this is an abnormal situation : the SELECT_LEX flag can be on only during query execution. Fixed by correctly cleaning up the SELECT_LEX flag when reusing the SELECT_LEX in a second execution.
-
- 26 Oct, 2009 1 commit
-
-
Georgi Kodinov authored
SP variables A function call may end without throwing an error or without setting the return value. This can happen when e.g. an error occurs while calculating the return value. Fixed by setting the value to NULL when error occurs during evaluation of an expression.
-
- 24 Oct, 2009 1 commit
-
-
Georgi Kodinov authored
-
- 23 Oct, 2009 7 commits
-
-
Ramil Kalimullin authored
-
Jon Olav Hauglid authored
-
Georgi Kodinov authored
fail.
-
Jon Olav Hauglid authored
This assertion would occur if UPDATE was used to update multiple tables containing an AUTO_INCREMENT column and if the inserted row had a user-supplied value for that column. The assertion could then be triggered by the next statement. The problem was only noticeable on debug builds of the server. The cause of the problem was that the code for multi update did not properly reset the TABLE->auto_increment_if_null flag after update. The flag is used to indicate that a non-null value of an auto_increment field has been provided by the user or retrieved from a current record. Open_tables() contains an assertion that tests this flag, and this was triggered in this case by ALTER TABLE. This patch fixes the problem by resetting the auto_increment_if_null field to FALSE once a row has been updated. This bug is similar to Bug#47274, but for multi update rather than INSERT DELAYED. Test case added to update.test.
-
Georgi Kodinov authored
-
Luis Soares authored
(automerge)
-
- 22 Oct, 2009 2 commits
-
-
Alfranio Correia authored
The label "end" was causing compiler warnings as it was no longer used. To fix the problem we removed it.
-
Ramil Kalimullin authored
-