- 20 Nov, 2009 5 commits
-
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Vladislav Vaintroub authored
-
Vladislav Vaintroub authored
implement Davi's review suggestions (post-push fixes)
-
- 19 Nov, 2009 1 commit
-
-
Georgi Kodinov authored
When merging ranges during calculation of the result of OR to two range sets the current range may be obsoleted by the resulting merged range. The first overlapping range can be obsoleted as well. Fixed by moving the pointer to the first overlapping range to the pointer of the resulting union range. Added few comments at key places in key_or().
-
- 20 Nov, 2009 2 commits
-
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
- 19 Nov, 2009 1 commit
-
-
Christopher Powers authored
Fixed crash caused by x64 int/long incompatibility introduced in Bug #29125.
-
- 18 Nov, 2009 7 commits
-
-
Georgi Kodinov authored
Fixed 2 errors in comp_err executable : 1. Wrong (off by 1) length passed to my_checksum() 2. strmov() was used on overlapping strings. This is not legal according to the docs in stpcpy(). Used the overlap safe memmove() instead.
-
Sven Sandberg authored
Problem: Some system functions that could return different values on master and slave were not marked unsafe. In particular: GET_LOCK IS_FREE_LOCK IS_USED_LOCK MASTER_POS_WAIT RELEASE_LOCK SLEEP SYSDATE VERSION Fix: Mark these functions unsafe.
-
Jon Olav Hauglid authored
Fixed a problem with the test case when executed with ps-protocol. There the conflicing lock would be noticed during prepare, not during execution of the insert - leading to a different (but equally appropriate) error message.
-
Mattias Jonsson authored
-
Magne Mahre authored
-
Magne Mahre authored
DELETE IGNORE The ER_CANT_UPDATE_USED_TABLE_IN_SF_OR_TRG error was set in the diagnostics area when it happened, but the DELETE cleanup code never checked for a non-fatal error condition, thus trying to set diag.area to "ok". This triggered an assert checking that the diag.area was empty. The fix was to test if there existed a non-fatal error condition (thd->is_error() before ok'ing the operation.
-
Jon Olav Hauglid authored
The problem was a "self-deadlock" if the connection issuing INSERT DELAYED had both the global read lock (FLUSH TABLES WITH READ LOCK) and LOCK TABLES mode active. The table being inserted into had to be different from the table(s) locked by LOCK TABLES. For INSERT DELAYED, the connection thread waits until the handler thread has opened and locked its table before returning. But since the global read lock was active, the handler thread would be unable to lock and would wait for the global read lock to go away. So the handler thread would be waiting for the connection thread to release the global read lock while the connection thread was waiting for the handler thread to lock the table. This gave a "self-deadlock" (same connection, different threads). The deadlock would only happen if we also had LOCK TABLES mode since the INSERT otherwise will try to get protection against global read lock before starting the handler thread. It will then notice that the global read lock is owned by the same connection and report ER_CANT_UPDATE_WITH_READLOCK. This patch removes the deadlock by reporting ER_CANT_UPDATE_WITH_READLOCK also if we are inside LOCK TABLES mode. Test case added to delayed.test.
-
- 17 Nov, 2009 8 commits
-
-
Mattias Jonsson authored
-
Mattias Jonsson authored
-
Mattias Jonsson authored
-
hery.ramilison@sun.com authored
-
Kent Boortz authored
-
Kent Boortz authored
-
Mattias Jonsson authored
-
Anurag Shekhar authored
-
- 13 Nov, 2009 1 commit
-
-
Jorgen Loland authored
init_read_record() - (records.cc:274) Item_cond::used_tables_cache was accessed in records.cc#init_read_record() without being initialized. It had not been initialized because it was wrongly assumed that the Item's variables would not be accessed, and hence quick_fix_field() was used instead of fix_fields() to save a few CPU cycles at creation time. The fix is to properly initilize the Item by replacing quick_fix_field() with fix_fields().
-
- 12 Nov, 2009 4 commits
-
-
Alexey Kopytov authored
-
Alexey Kopytov authored
-
Alexey Kopytov authored
-
Magne Mahre authored
deadlock was encountered The bug is caused by an inconsistent handling of the IGNORE clause. A read from a const table caused a lock timeout (ER_LOCK_TIMEOUT) in innodb. Since the IGNORE clause was given, the timeout was converted into a warning instead of an error, thus not populating the diagnostics area. When innodb subsequently marked the transaction for rollback, mysql asserted since the diag.area was empty. This patch consists of only a test case, as the bug itself was fixed by the patch for Bug #46539
-
- 11 Nov, 2009 2 commits
-
-
Christopher Powers authored
-
Anurag Shekhar authored
on any access Archive engine for 5.1 (and latter) version uses a modified version of zlib (azlib). These two version are incompatible so a proper upgrade is needed before tables created in 5.0 can be used reliable. This upgrade can be performed using repair. But due to lack of test its risky to allow upgrade for now. This patch addresses only the crashing issue. Any attempt to repair will be blocked. Eventually repair can be allowed to run through (which will also cause an upgrade from older version to newer) but only after a thorough testing.
-
- 10 Nov, 2009 1 commit
-
-
Christopher Powers authored
The crash occurs because SAFEMALLOC is defined for the MySQL server but not for the Archive or Federated engines, resulting in a parameter mismatch between the function prototype and definition for functions using the CALLER_INFO macro.
-
- 09 Nov, 2009 2 commits
-
-
hery.ramilison@sun.com authored
-
Georgi Kodinov authored
memory The server was doing a bad class typecast causing setting of wrong value for the maximum number of items in an internal structure used in equality propagation. Fixed by not doing the wrong typecast and asserting the type of the Item where it should be done.
-
- 10 Nov, 2009 1 commit
-
-
Georgi Kodinov authored
values We should re-set the access method functions when changing the access method when switching to another index to avoid sorting. Fixed by doing a little re-engineering : encapsulating all the function assignment into a special function and calling it when flipping the indexes.
-
- 09 Nov, 2009 1 commit
-
-
Mattias Jonsson authored
Bug when setting up default partitioning, used an uninitialized variabe.
-
- 06 Nov, 2009 4 commits
-
-
Evgeny Potemkin authored
-
Evgeny Potemkin authored
When values of different types are compared they're converted to a type that allows correct comparison. This conversion is done for each comparison and takes some time. When a constant is being compared it's possible to cache the value after conversion to speedup comparison. In some cases (large dataset, complex WHERE condition with many type conversions) query might be executed 7% faster. A test case isn't provided because all changes are internal and isn't visible outside. The behavior of the Item_cache is changed to cache values on the first request of cached value rather than at the moment of storing item to be cached. A flag named value_cached is added to the Item_cache class. It's set to TRUE when cache holds the value of the last stored item. Function named cache_value() is added to the Item_cache class and derived classes. This function actually caches the value of the saved item. Item_cache_xxx::store functions now only store item to be cached and set value_cached flag to FALSE. Item_cache_xxx::val_xxx functions are changed to call cache_value function prior to returning cached value if value_cached is FALSE. The Arg_comparator::set_cmp_func function now calls cache_converted_constant to cache constants if they need a type conversion. The Item_cache::get_cache function is overloaded to allow setting of the cache type. The cache_converted_constant function is added to the Arg_comparator class. It checks whether a value can and should be cached and if so caches it.
-
Luis Soares authored
-
Alexey Kopytov authored
-