- 23 Oct, 2009 3 commits
-
-
Georgi Kodinov authored
-
unknown authored
Added parentheses around assignment used as truth value for suppressing warnings.
-
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
-
- 21 Oct, 2009 4 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. mysql-test/r/select.result: Fix for bug#47019: Assertion failed: 0, file .\rt_mbr.c, line 138 when forcing a spatial index - test result. mysql-test/t/select.test: Fix for bug#47019: Assertion failed: 0, file .\rt_mbr.c, line 138 when forcing a spatial index - test case. sql/sql_select.cc: Fix for bug#47019: Assertion failed: 0, file .\rt_mbr.c, line 138 when forcing a spatial index - disable spatial indexes for queries which use non-spatial conditions (e.g. NATURAL JOINs).
-
Bjorn Munch authored
-
Tatiana A. Nurnberg authored
-
Tatiana A. Nurnberg authored
-
- 20 Oct, 2009 14 commits
-
-
Tatiana A. Nurnberg authored
-
Bjorn Munch authored
-
Luis Soares authored
file Issuing 'FLUSH LOGS' does not close and reopen indexfile. Instead a SEEK_SET is performed. This patch makes index file to be closed and reopened whenever a rotation happens (FLUSH LOGS is issued or binary log exceeds maximum configured size). mysql-test/suite/binlog/r/binlog_delete_and_flush_index.result: Result file. mysql-test/suite/binlog/t/binlog_delete_and_flush_index.test: Test case. sql/log.cc: Added LOG_CLOSE_INDEX flag when calling MYSQL_BIN_LOG::close from within MYSQL_BIN_LOG::new_file_impl (which should just be called whenever a rotation is to happen - FLUSH LOGS issued or binlog size exceeds the maximum configured).
-
Alexander Barkov authored
- Initialized caseinfo only if it is NULL
-
Kristofer Pettersson authored
-
Satya B authored
-
Satya B authored
-
Satya B authored
-
Kristofer Pettersson 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 mysql-test/r/grant3.result: Bug #41597 - After rename of user, there are additional grants when grants are reapplied. Testcase for BUG#41597 mysql-test/t/grant3.test: Bug #41597 - After rename of user, there are additional grants when grants are reapplied. Testcase for BUG#41597 sql/sql_acl.cc: Bug #41597 - After rename of user, there are additional grants when grants are reapplied. Fixed handle_grant_struct() to update the hash key when the user is renamed. Added to set_user_details() method to GRANT_NAME class
-
Sergey Vojtovich authored
-
Sergey Vojtovich authored
-
unknown authored
There are some problems about help text: - It is stated that "auto" is the default twice. It need be stated only once. - It is stated that --base64-output is short for --base64-output=always. But that sounds like the default is "always", not "auto". Make the help text clear as following: Determine when the output statements should be base64-encoded BINLOG statements: 'never' disables it and works only for binlogs without row-based events; 'auto' prints base64 only when necessary (i.e., for row-based events and format description events); 'always' prints base64 whenever possible. 'always' is for debugging only and should not be used in a production system. If this argument is not given, the default is 'auto'; if it is given with no argument, 'always' is used.
-
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. client/mysql.cc: Extends Control-C handling; enhances up feedback to user. On 5.0+ servers, we try to be nice and send KILL QUERY first if Control-C is pressed in the command-line client, but if that doesn't work, we now give the user the opportunity to send KILL CONNECTION with another Control-C (and to kill the client with another Control-C if that somehow doesn't work either). mysql-test/t/flush_read_lock_kill.test: we're getting correct "thread killed" rather than "in shutdown" error now mysql-test/t/kill.test: we're getting correct "thread killed" rather than "in shutdown" error now mysql-test/t/rpl000001.test: we're getting correct "thread killed" rather than "in shutdown" error now mysql-test/t/rpl_error_ignored_table.test: we're getting correct "thread killed" rather than "in shutdown" error now sql/records.cc: make error messages on KILL uniform for rr_*() by folding that handling into rr_handle_error() sql/sql_class.h: Only throw "shutdown" when we have one flagged as being in progress; otherwise, throw "query interrupted" as it's likely to be "KILL CONNECTION" or related.
-
- 19 Oct, 2009 8 commits
-
-
Bjorn Munch authored
Knowledge of no SSL support is not used Skip tests the same way e.g. innodb tests are Does not refer to have_ssl_communication.inc, will add this when merging to 6.0-codebase
-
Bjorn Munch authored
-
Alexander Barkov authored
Problem: the "caseinfo" member of CHARSET_INFO structure was not initialized for user-defined Unicode collations, which made the server crash. Fix: initializing caseinfo properly.
-
Kristofer Pettersson authored
-
Kristofer Pettersson authored
-
Alexander Barkov authored
Adding tests for the bug.
-
Alexander Barkov authored
A contributed patch by Andrei Boros (SCA signed). - Fixing locale definition file - Adding tests
-
Kristofer Pettersson authored
Adding @@session and @@global prefixes to a declared variable in a stored procedure the server would lead to a crash. The reason was that during the parsing of the syntactic rule 'option_value' an uninitialized set_var object was pushed to the parameter stack of the SET statement. The parent rule 'option_type_value' interpreted the existence of variables on the parameter stack as an assignment and wrapped it in a sp_instr_set object. As the procedure later was executed an attempt was made to run the method 'check()' on an uninitialized member object (NULL value) belonging to the previously created but uninitialized object. sql/sql_yacc.yy: * Assign the option_type at once since it is needed by the next parsing rule (internal_variable_name) * Rearranged the if statement to reduce negations and gain more clarity of code. * Added check for option_type to better detect if current variable is a SP local variable or a system variable.
-
- 18 Oct, 2009 2 commits
-
-
Ramil Kalimullin authored
Problem: using null microsecond part in a WHERE condition (e.g. WHERE date_time_field <= "YYYY-MM-DD HH:MM:SS.0000") may lead to wrong results due to improper DATETIMEs comparison in some cases. Fix: comparing DATETIMEs as strings we must trim trailing 0's in such cases. mysql-test/r/innodb_mysql.result: Fix for bug#47963: Wrong results when index is used - test result. mysql-test/t/innodb_mysql.test: Fix for bug#47963: Wrong results when index is used - test case. sql/item.cc: Fix for bug#47963: Wrong results when index is used - comparing DATETIMEs as strings we must trim trailing 0's in the microsecond part to ensure 'YYYY-MM-DD HH:MM:SS.000' == 'YYYY-MM-DD HH:MM:SS'
-
Bjorn Munch authored
Don't print entire log, but use extract_server_log() introduced by 46007
-
- 17 Oct, 2009 1 commit
-
-
Bjorn Munch authored
Test batches may be terminated too early Avoid counting exp-fail tests
-
- 16 Oct, 2009 6 commits
-
-
Bjorn Munch authored
-
Alexey Kopytov authored
The problem was in incorrect handling of predicates involving NULL as a constant value by the range optimizer. For example, when creating a SEL_ARG node from a condition of the form "field < const" (which would normally result in the "NULL < field < const" SEL_ARG), the special case when "const" is NULL was not taken into account, so "NULL < field < NULL" was produced for the "field < NULL" condition. As a result, SEL_ARG structures of this form could not be further optimized which in turn could lead to incorrectly constructed SEL_ARG trees. In particular, code assuming SEL_ARG structures to always form a sequence of ordered disjoint intervals could enter an infinite loop under some circumstances. Fixed by changing get_mm_leaf() so that for any sargable predicate except "<=>" involving NULL as a constant, "empty" SEL_ARG is returned, since such a predicate is always false. mysql-test/r/partition_pruning.result: Fixed a broken test case. mysql-test/r/range.result: Added a test case for bug #47123. mysql-test/r/subselect.result: Fixed a broken test cases. mysql-test/t/range.test: Added a test case for bug #47123. sql/opt_range.cc: Fixed get_mm_leaf() so that for any sargable predicate except "<=>" involving NULL as a constant, "empty" SEL_ARG is returned, since such a predicate is always false.
-
Joerg Bruehe authored
-
Joerg Bruehe authored
-
Joerg Bruehe authored
-
Joerg Bruehe authored
-