- 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 8 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
-
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.
-
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 5 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.
-
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).
-
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).
-
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
-
Sergey Vojtovich authored
-
Sergey Vojtovich 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.
-
- 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.
-
- 18 Oct, 2009 1 commit
-
-
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.
-