- 14 Jun, 2010 3 commits
-
-
Bjorn Munch authored
-
Bjorn Munch authored
-
Bjorn Munch authored
Kill mysqltest and call mtr_kill_leftovers() before terminating
-
- 12 Jun, 2010 2 commits
-
-
Alexey Kopytov authored
conflicts: conflict sql/sql_prepare.cc
-
Alexey Kopytov authored
In Prepared_statement::prepare() bail out as soon as parser_state.init() fails, trying to continue leads to crashes.
-
- 11 Jun, 2010 12 commits
-
-
Alexey Kopytov authored
-
Alexey Kopytov authored
-
Alexey Kopytov authored
-
Ramil Kalimullin authored
-
Ramil Kalimullin authored
-
Alexey Kopytov authored
-
Alexey Kopytov authored
conflicts: conflict mysys/safemalloc.c conflict sql/mysqld.cc conflict sql/sp.cc conflict sql/sql_lex.cc conflict sql/sql_lex.h conflict sql/sql_parse.cc conflict sql/sql_prepare.cc
-
Alexey Kopytov authored
conflicts: conflict sql/sql_parse.cc
-
Alexey Kopytov authored
conflicts: conflict sql/sql_parse.cc
-
Martin Hansson authored
-
Martin Hansson authored
Item*) at opt_sum.cc:305 Queries applying MIN/MAX functions to indexed columns are optimized to read directly from the index if all key parts of the index preceding the aggregated key part are bound to constants by the WHERE clause. A prefix length is also produced, equal to the total length of the bound key parts. If the aggregated column itself is bound to a constant, however, it is also included in the prefix. Such full search keys are read as closed intervals for reasons beyond the scope of this bug. However, the procedure missed one case where a key part meant for use as range endpoint was being overwritten with a NULL value destined for equality checking. In this case the key part was overwritten but the range flag remained, causing open interval reading to be performed. Bug was fixed by adding more stringent checking to the search key building procedure (matching_cond) and never allow overwrites of range predicates with non-range predicates. An assertion was added to make sure open intervals are never used with full search keys.
-
Davi Arnaut authored
-
- 10 Jun, 2010 10 commits
-
-
Davi Arnaut authored
strict aliasing violations. One somewhat major source of strict-aliasing violations and related warnings is the SQL_LIST structure. For example, consider its member function `link_in_list` which takes a pointer to pointer of type T (any type) as a pointer to pointer to unsigned char. Dereferencing this pointer, which is done to reset the next field, violates strict-aliasing rules and might cause problems for surrounding code that uses the next field of the object being added to the list. The solution is to use templates to parametrize the SQL_LIST structure in order to deference the pointers with compatible types. As a side bonus, it becomes possible to remove quite a few casts related to acessing data members of SQL_LIST.
-
Davi Arnaut authored
strict aliasing violations. Essentially, the problem is that large parts of the server were developed in simpler times (last decades, pre C99 standard) when strict aliasing and compilers supporting such optimizations were rare to non-existent. Thus, when compiling the server with a modern compiler that uses strict aliasing rules to perform optimizations, there are several places in the code that might trigger undefined behavior. As evinced by some recent bugs, GCC does a somewhat good of job misoptimizing such code, but on the other hand also gives warnings about suspicious code. One problem is that the warnings aren't always accurate, yet we can't afford to just shut them off as we might miss real cases. False-positive cases are aggravated mostly by casts that are likely to trigger undefined behavior. The solution is to start a cleanup process focused on fixing and reducing the amount of strict-aliasing related warnings produced by GCC and others compilers. A good deal of noise reduction can be achieved by just removing useless casts that are product of historical cruft and are likely to trigger undefined behavior if dereferenced.
-
Alexander Nozdrin authored
-
Alexander Nozdrin authored
Revision ID of the patch: marc.alff@oracle.com-20100608124148-lr1ult7lwo75niev
-
Tor Didriksen authored
text conflict: unittest/examples/Makefile.am
-
Tor Didriksen authored
The bug was caused by buffered output. Flushing resolved it. We still recommend to allways call plan(). Also fix some compile warnings (formal parameter different from declaration)
-
Alexander Nozdrin authored
-
Davi Arnaut authored
-
Davi Arnaut authored
-
Davi Arnaut authored
Addendum: Work around a compilation failure on Windows due to windows.h not being added to the global namespace.
-
- 09 Jun, 2010 3 commits
-
-
Ramil Kalimullin authored
Problem: the server missed the fact that one can read from 2 indexes alternately using HANDLER interface. Fix: check if the same (initialized) index is involved reading next/prev values from the index.
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
- 08 Jun, 2010 10 commits
-
-
Davi Arnaut authored
-
Davi Arnaut authored
-
Davi Arnaut authored
-
Davi Arnaut authored
The problem was that the bundled yaSSL library was being built without thread safety support regardless of the thread safeness of the compoments linked with it. The solution is to enable yaSSL thread safety support if any component (server or client) is to be built with thread support. Also, generate new certificates for yaSSL's test suite.
-
Marc Alff authored
Prior to this fix, mysys mutexes such as THR_LOCK_lock could be initialized twice by a call to my_init(). The root cause was out of place initialization in my_basic_init(), calling my_thread_global_init(). With this fix, - my_basic_init() properly initializes the mutex implementation itself, for SAFE or FAST mutexes, and for platform dependent initializations, before initialiazing a mutex. - my_init() properly initializes mysys mutexes once, when making the first call to my_thread_global_init().
-
Kristofer Pettersson authored
-
Kristofer Pettersson authored
-
Georgi Kodinov authored
Fixed the failing sys_vars.timestamp_basic.test by not re-calculating the value of the system variable at check time.
-
Kristofer Pettersson authored
-
Kristofer Pettersson authored
Logging slow stored procedures caused the slow log to write very large lock times. The lock times was a result of a negative number being cast to an unsigned integer. The reason the lock time appeard negative was because one of the measurements points was reset after execution causing it to change order with the start time of the statement. This bug is related to bug 47905 which in turn was introduced because of a joint fix for 12480,12481,12482 and 11587. The fix is to only reset the start_time before any statement execution in a SP while not resetting start_utime or utime_after_lock which are used for measuring the performance of the SP. Start_time is used to set the timestamp on the replication event which controlls how the slave interprets time functions like NOW().
-