1. 20 Nov, 2009 1 commit
  2. 18 Nov, 2009 5 commits
    • Georgi Kodinov's avatar
      Bug#48864: MySQL fails to compile on 64 bit Fedora 12 · 6b3b2c0c
      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.
      6b3b2c0c
    • Mattias Jonsson's avatar
      merge · 9e1f4b9b
      Mattias Jonsson authored
      9e1f4b9b
    • Magne Mahre's avatar
      merge · c37250dd
      Magne Mahre authored
      c37250dd
    • Magne Mahre's avatar
      Bug #46425 crash in Diagnostics_area::set_ok_status , empty statement, · 9e6cb377
      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.
      9e6cb377
    • Jon Olav Hauglid's avatar
      Bug #47682 strange behaviour of INSERT DELAYED · a6733b52
      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.
      a6733b52
  3. 17 Nov, 2009 7 commits
  4. 13 Nov, 2009 1 commit
    • Jorgen Loland's avatar
      Bug#48052: Valgrind warning - uninitialized value in · 2a254a13
      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().
      2a254a13
  5. 12 Nov, 2009 4 commits
  6. 11 Nov, 2009 2 commits
    • Christopher Powers's avatar
      Merge · edfd29dd
      Christopher Powers authored
      edfd29dd
    • Anurag Shekhar's avatar
      Bug #47012 archive tables are not upgradeable, and server crashes · 862c422c
      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.
      862c422c
  7. 10 Nov, 2009 1 commit
    • Christopher Powers's avatar
      Bug#47382 'mysqladmin debug' crash on 64-bit Windows · 9bb40dc1
      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.
      9bb40dc1
  8. 09 Nov, 2009 1 commit
    • Georgi Kodinov's avatar
      Bug #48458: simple query tries to allocate enormous amount of · 48c67b2c
      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.
      48c67b2c
  9. 10 Nov, 2009 1 commit
    • Georgi Kodinov's avatar
      Bug #42760: Select doesn't return desired results when we have null · 154c3480
      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.
      154c3480
  10. 09 Nov, 2009 1 commit
  11. 06 Nov, 2009 8 commits
    • Evgeny Potemkin's avatar
      Auto-merged fix for the bug#34384. · 47d850a8
      Evgeny Potemkin authored
      47d850a8
    • Evgeny Potemkin's avatar
      Bug#34384: Slow down on constant conversion. · 60d358af
      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.
      60d358af
    • Luis Soares's avatar
    • Alexey Kopytov's avatar
      Automerge. · 1a90c5f7
      Alexey Kopytov authored
      1a90c5f7
    • Alexey Kopytov's avatar
      Automerge. · 91829c0a
      Alexey Kopytov authored
      91829c0a
    • Alexey Kopytov's avatar
      Automerge. · 5d725601
      Alexey Kopytov authored
      5d725601
    • Alexey Kopytov's avatar
      Automerge. · 9674ef68
      Alexey Kopytov authored
      9674ef68
    • Alexey Kopytov's avatar
      Bug #48475: DISTINCT is ignored with GROUP BY WITH ROLLUP and · 9fff9acf
      Alexey Kopytov authored
                  only const tables
      
      The problem was caused by two shortcuts in the optimizer that
      are inapplicable in the ROLLUP case.
      
      Normally in a case when only const tables are involved in a
      query, DISTINCT clause can be safely optimized away since there
      may be only one row produced by the join. Similarly, we don't
      need to create a temporary table to resolve DISTINCT/GROUP
      BY/ORDER BY. Both of these are inapplicable when the WITH
      ROLLUP modifier is present.
      
      Fixed by disabling the said optimizations for the WITH ROLLUP
      case.
      9fff9acf
  12. 04 Nov, 2009 6 commits
    • Timothy Smith's avatar
      auto-merge · 2b87e80a
      Timothy Smith authored
      2b87e80a
    • Timothy Smith's avatar
      auto-merge · 377c1dc5
      Timothy Smith authored
      377c1dc5
    • Timothy Smith's avatar
      Fix for Bug#40700: aclocal warnings for missing cache-id's · 6d79f4a1
      Timothy Smith authored
      Just change mysql_foo to mysql_cv_foo for one cache-id variable name.  There
      was only one bad variable name, present in 5.0 and 5.1, but not in the -pe
      branch.
      6d79f4a1
    • Timothy Smith's avatar
      auto-merge · ed1b8829
      Timothy Smith authored
      ed1b8829
    • Timothy Smith's avatar
      auto-merge · 9a95a85c
      Timothy Smith authored
      9a95a85c
    • Georgi Kodinov's avatar
      Bug #46175: NULL read_view and consistent read assertion · 9ba74e5d
      Georgi Kodinov authored
      The SE API requires mysql to notify the storage engine that
      it's going to read certain tables at the beginning of the 
      statement (by calling start_stmt(), store_lock() or
      external_lock()).
      These are typically called by the lock_tables(). 
      However SHOW CREATE TABLE is not pre-locking the tables
      because it's not expected to access the data at all.
      But for some view definitions (that include comparing a
      date/datetime/timestamp column to a string returning
      scalar subquery) the JOIN::prepare may still access data
      when materializing the scalar non-correlated subquery
      in Arg_comparator::can_compare_as_dates().
      Fixed by not materializing the subquery when the function
      is called in a SHOW/EXPLAIN/CREATE VIEW
      9ba74e5d
  13. 05 Nov, 2009 2 commits