1. 09 Nov, 2009 2 commits
  2. 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
  3. 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
  4. 05 Nov, 2009 2 commits
  5. 04 Nov, 2009 3 commits
    • Georgi Kodinov's avatar
      merge · c96baff6
      Georgi Kodinov authored
      c96baff6
    • Georgi Kodinov's avatar
    • Luis Soares's avatar
      BUG#47743: rpl.rpl_log_pos fails sporadically · 49fe3f5f
      Luis Soares authored
      BUG#47983: rpl_extraColmaster_myisam failed in PB2 with "Found
      warnings!!"
      
      BUG 45214 fixed the case when get_master_version_and_clock
      function, used by the slave, would not report errors. The slave
      now detects them and if related to transient network failures, it
      prints some warnings and retries to connect. On the other hand,
      if not network related, it just gives up and fails.
      
      As such, sometimes, in PB2, the slave comes across some transient
      communication issues between master and slave, while calling
      get_master_version_and_clock, causing warnings print outs to the
      error log. Nevertheless, in such cases slave retries to connect,
      in which it succeeds, and the test case continues as it normally
      would. But then, at the end of a successful test run, MTR checks
      the error log, finds the unexpected warnings and considers them
      harmful. This causes MTR to report error and, consequently, PB2
      to report a failing test.
      
      We fix this by adding to the global warnings suppress list the
      warnings related to transient network failures only, which are
      reported while in function get_master_version_and_clock.
      49fe3f5f
  6. 03 Nov, 2009 19 commits
    • Timothy Smith's avatar
    • Timothy Smith's avatar
      Bug#48031: mysql_secure_installation -- bash bug regarding passwords with · 3aff1e95
      Timothy Smith authored
        special chars
      
      This script failed when the user tried passwords with multiple spaces, \, # or
      ' characters.  Now proper escaping and quoting is used in all contexts.
      
      This problem occurs in the Perl version of this script, too, so fix it in both
      places.
      3aff1e95
    • Timothy Smith's avatar
      Bug#48086: mysql_secure_installation does NOT work on Solaris · 9e7cd0fb
      Timothy Smith authored
      Remove a bash-ism (if ! ...).
      9e7cd0fb
    • Davi Arnaut's avatar
      Automerge. · ca00c92d
      Davi Arnaut authored
      ca00c92d
    • Davi Arnaut's avatar
      fc55339e
    • Konstantin Osipov's avatar
      A fix and a test case for · 409160e4
      Konstantin Osipov authored
      Bug#41756 "Strange error messages about locks from InnoDB".
            
      In JT_EQ_REF (join_read_key()) access method, 
      don't try to unlock rows in the handler, unless certain that 
      a) they were locked
      b) they are not used.
      
      Unlocking of rows is done by the logic of the nested join loop,
      and is unaware of the possible caching that the access method may
      have. This could lead to double unlocking, when a row
      was unlocked first after reading into the cache, and then 
      when taken from cache, as well as to unlocking of rows which
      were actually used (but taken from cache).
            
      Delegate part of the unlocking logic to the access method,
      and in JT_EQ_REF count how many times a record was actually 
      used in the join. Unlock it only if it's usage count is 0.
      
      Implemented review comments.
      409160e4
    • Magnus Blåudd's avatar
      Merge bug#47867 to 5.1-bugteam · 273f9b63
      Magnus Blåudd authored
      273f9b63
    • Konstantin Osipov's avatar
      A fix and a test case for · d2babeaf
      Konstantin Osipov authored
      Bug#41756 "Strange error messages about locks from InnoDB".
      
      In JT_EQ_REF (join_read_key()) access method,
      don't try to unlock rows in the handler, unless certain that
      a) they were locked
      b) they are not used.
      
      Unlocking of rows is done by the logic of the nested join loop,
      and is unaware of the possible caching that the access method may
      have. This could lead to double unlocking, when a row
      was unlocked first after reading into the cache, and then
      when taken from cache, as well as to unlocking of rows which
      were actually used (but taken from cache).
      
      Delegate part of the unlocking logic to the access method,
      and in JT_EQ_REF count how many times a record was actually
      used in the join. Unlock it only if it's usage count is 0.
      
      Implemented review comments.
      d2babeaf
    • Kristofer Pettersson's avatar
      automerge · 6eec4b98
      Kristofer Pettersson authored
      6eec4b98
    • Kristofer Pettersson's avatar
    • Sergey Vojtovich's avatar
      Merge of innodb-zip-ss6129 snapshot. · 2ebdc909
      Sergey Vojtovich authored
      2ebdc909
    • Sergey Vojtovich's avatar
      Clean-up after applying innodb-zip-ss6129 snapshot: · af3c70af
      Sergey Vojtovich authored
      - re-enabled main.innodb_bug44369;
      - re-enabled main.innodb_bug47777;
      - re-enabled innodb.innodb_information_schema.
      af3c70af
    • Jorgen Loland's avatar
      Bug#48177 - SELECTs with NOT IN subqueries containing NULL · 7f9a5047
      Jorgen Loland authored
                  values return too many records
      
      WHERE clauses with "outer_value_list NOT IN subselect" were
      handled incorrectly if the outer value list contained multiple 
      items where at least one of these could be NULL. The first 
      outer record with NULL value was handled correctly, but if a 
      second record with NULL value existed, the optimizer would 
      choose to reuse the result it got on the last execution of the 
      subselect. This is incorrect if the outer value list has 
      multiple items.
           
      The fix is to make Item_in_optimizer::val_int (in 
      item_cmpfunc.cc) reuse the result of the latest execution
      for NULL values only if all values in the outer_value_list 
      are NULL.
      7f9a5047
    • Sergey Vojtovich's avatar
      Applying InnoDB plugin snashot · b9f3a76a
      Sergey Vojtovich authored
      Detailed revision comments:
      
      r6126 | vasil | 2009-10-30 10:36:07 +0200 (Fri, 30 Oct 2009) | 45 lines
      branches/zip: Merge r6112:6125 from branches/5.1:
      
      (skipping r6122 and r6123, Jimmy says these are already present and need
      not be merged):
      
        ------------------------------------------------------------------------
        r6122 | jyang | 2009-10-30 05:18:38 +0200 (Fri, 30 Oct 2009) | 7 lines
        Changed paths:
           M /branches/5.1/handler/ha_innodb.cc
           M /branches/5.1/mysql-test/innodb_bug44369.result
           M /branches/5.1/mysql-test/innodb_bug44369.test
           M /branches/5.1/mysql-test/innodb_bug46000.result
           M /branches/5.1/mysql-test/innodb_bug46000.test
        
        branches/5.1: Chnage WARN_LEVEL_ERROR to WARN_LEVEL_WARN
        for push_warning_printf() call in innodb.
        Fix Bug#47233: Innodb calls push_warning(MYSQL_ERROR::WARN_LEVEL_ERROR)
        
        rb://170 approved by Marko.
        
        
        ------------------------------------------------------------------------
        r6123 | jyang | 2009-10-30 05:43:06 +0200 (Fri, 30 Oct 2009) | 8 lines
        Changed paths:
           M /branches/5.1/os/os0proc.c
        
        branches/5.1: In os_mem_alloc_large(), if we fail to attach
        the shared memory, reset memory pointer ptr to NULL, and
        allocate memory from conventional pool. This is a port
        from branches/zip.
        Bug #48237 Error handling in os_mem_alloc_large appears to be incorrect
        rb://198  Approved by: Marko
        
        
        ------------------------------------------------------------------------
        r6125 | vasil | 2009-10-30 10:31:23 +0200 (Fri, 30 Oct 2009) | 4 lines
        Changed paths:
           M /branches/5.1/handler/ha_innodb.cc
        
        branches/5.1:
        
        White-space fixup.
        
        ------------------------------------------------------------------------
      b9f3a76a
    • Sergey Vojtovich's avatar
      Applying InnoDB plugin snashot · f578a61d
      Sergey Vojtovich authored
      Detailed revision comments:
      
      r6121 | sunny | 2009-10-30 01:42:11 +0200 (Fri, 30 Oct 2009) | 7 lines
      branches/zip: This test has been problematic for sometime now. The underlying
      bug is that the data dictionaries get out of sync. In the AUTOINC code we
      try and apply salve to the symptoms. In the past MySQL made some unrelated
      change and the dictionaries stopped getting out of sync and this test started
      to fail. Now, it seems they have reverted that changed and the test is
      passing again. I suspect this is not he last time that this test will change.
      
      r6124 | jyang | 2009-10-30 10:02:31 +0200 (Fri, 30 Oct 2009) | 5 lines
      branches/zip: Correct the bug number for -r6109 change
      from # 48273 to #48237
      f578a61d
    • Sergey Vojtovich's avatar
      Applying InnoDB plugin snashot · 895db582
      Sergey Vojtovich authored
      Detailed revision comments:
      
      r6114 | vasil | 2009-10-29 18:43:51 +0200 (Thu, 29 Oct 2009) | 6 lines
      branches/zip:
      
      * Add ChangeLog entries for latest changes
      * Obey alphabetical order in the list of the files
      * White-space fixup
      895db582
    • Sergey Vojtovich's avatar
      Applying InnoDB plugin snashot · 02ba9d61
      Sergey Vojtovich authored
      Detailed revision comments:
      
      r6113 | vasil | 2009-10-29 18:15:50 +0200 (Thu, 29 Oct 2009) | 93 lines
      branches/zip: Merge r5912:6112 from branches/5.1:
      
      (after this merge the innodb-autoinc test starts to fail, but
      I commit anyway because it would be easier to investigate the
      failure this way)
      
        ------------------------------------------------------------------------
        r5952 | calvin | 2009-09-22 19:45:07 +0300 (Tue, 22 Sep 2009) | 7 lines
        Changed paths:
           M /branches/5.1/handler/ha_innodb.cc
        
        branches/5.1: fix bug#42383: Can't create table 'test.bug39438'
        
        For embedded server, MySQL may pass in full path, which is
        currently disallowed. It is needed to relax the condition by
        accepting full paths in the embedded case.
        
        Approved by: Heikki (on IM)
        ------------------------------------------------------------------------
        r6032 | vasil | 2009-10-01 15:55:49 +0300 (Thu, 01 Oct 2009) | 8 lines
        Changed paths:
           M /branches/5.1/handler/ha_innodb.cc
        
        branches/5.1:
        
        Fix Bug#38996 Race condition in ANALYZE TABLE
        
        by serializing ANALYZE TABLE inside InnoDB.
        
        Approved by:	Heikki (rb://175)
        
        ------------------------------------------------------------------------
        r6045 | jyang | 2009-10-08 02:27:08 +0300 (Thu, 08 Oct 2009) | 7 lines
        Changed paths:
           M /branches/5.1/handler/ha_innodb.cc
           A /branches/5.1/mysql-test/innodb_bug47777.result
           A /branches/5.1/mysql-test/innodb_bug47777.test
        
        branches/5.1: Fix bug #47777. Treat the Geometry data same as
        Binary BLOB in ha_innobase::store_key_val_for_row(), since the
        Geometry data is stored as Binary BLOB in Innodb.
        
        Review: rb://180 approved by Marko Makela.
        
        
        ------------------------------------------------------------------------
        r6051 | sunny | 2009-10-12 07:05:00 +0300 (Mon, 12 Oct 2009) | 6 lines
        Changed paths:
           M /branches/5.1/handler/ha_innodb.cc
           M /branches/5.1/mysql-test/innodb-autoinc.result
           M /branches/5.1/mysql-test/innodb-autoinc.test
        
        branches/5.1: Ignore negative values supplied by the user when calculating the
        next value to store in dict_table_t. Setting autoincrement columns top negative
        values is undefined behavior and this change should bring the behavior of
        InnoDB closer to what users expect. Added several tests to check.
        rb://162
        
        ------------------------------------------------------------------------
        r6052 | sunny | 2009-10-12 07:09:56 +0300 (Mon, 12 Oct 2009) | 4 lines
        Changed paths:
           M /branches/5.1/handler/ha_innodb.cc
           M /branches/5.1/mysql-test/innodb-autoinc.result
           M /branches/5.1/mysql-test/innodb-autoinc.test
        
        branches/5.1: Reset the statement level autoinc counter on ROLLBACK. Fix
        the test results too.
        rb://164
        
        ------------------------------------------------------------------------
        r6053 | sunny | 2009-10-12 07:37:49 +0300 (Mon, 12 Oct 2009) | 6 lines
        Changed paths:
           M /branches/5.1/handler/ha_innodb.cc
           M /branches/5.1/mysql-test/innodb-autoinc.result
           M /branches/5.1/mysql-test/innodb-autoinc.test
        
        branches/5.1: Copy the maximum AUTOINC value from the old table to the new
        table when MySQL does a CREATE INDEX ON T. This is required because MySQL
        does a table copy, rename and drops the old table.
        Fix Bug#47125: auto_increment start value is ignored if an index is created and engine=innodb
        rb://168
        
        ------------------------------------------------------------------------
        r6076 | vasil | 2009-10-14 19:30:12 +0300 (Wed, 14 Oct 2009) | 4 lines
        Changed paths:
           M /branches/5.1/row/row0mysql.c
        
        branches/5.1:
        
        Fix typo.
        
        ------------------------------------------------------------------------
      02ba9d61
    • Sergey Vojtovich's avatar
      Applying InnoDB plugin snashot · 7559c6ae
      Sergey Vojtovich authored
      Detailed revision comments:
      
      r6112 | calvin | 2009-10-29 16:21:15 +0200 (Thu, 29 Oct 2009) | 4 lines
      branches/zip: consideration for icc compilers
      
      Proposed by MySQL, and approved by Marko.
      7559c6ae
    • Sergey Vojtovich's avatar
      Applying InnoDB plugin snashot · aa14038f
      Sergey Vojtovich authored
      Detailed revision comments:
      
      r6110 | marko | 2009-10-29 12:44:57 +0200 (Thu, 29 Oct 2009) | 2 lines
      branches/zip: Makefile.am (INCLUDES): Merge a change from MySQL:
      Use $(srcdir)/include instead of $(top_srcdir)/storage/innobase/include.
      r6111 | marko | 2009-10-29 13:04:11 +0200 (Thu, 29 Oct 2009) | 33 lines
      branches/zip: Fix corruption of buf_pool->LRU_old and improve debug assertions.
      This was reported as Issue #381.
      
      buf_page_set_old(): Assert that blocks may only be set old if
      buf_pool->LRU_old is initialized and buf_pool->LRU_old_len is nonzero.
      Assert that buf_pool->LRU_old points to the block at the old/new boundary.
      
      buf_LRU_old_adjust_len(): Invoke buf_page_set_old() after adjusting
      buf_pool->LRU_old and buf_pool->LRU_old_len, in order not to violate
      the added assertions.
      
      buf_LRU_old_init(): Replace buf_page_set_old() with a direct
      assignment to bpage->old, because these loops that initialize all the
      blocks would temporarily violate the assertions about
      buf_pool->LRU_old.
      
      buf_LRU_remove_block(): When setting buf_pool->LRU_old = NULL, also
      clear all bpage->old flags and set buf_pool->LRU_old_len = 0.
      
      buf_LRU_add_block_to_end_low(), buf_LRU_add_block_low(): Move the
      buf_page_set_old() call later in order not to violate the debug
      assertions.  If buf_pool->LRU_old is NULL, set old=FALSE.
      
      buf_LRU_free_block(): Replace the UNIV_LRU_DEBUG assertion with a
      dummy buf_page_set_old() call that performs more thorough checks.
      
      buf_LRU_validate(): Do not tolerate garbage in buf_pool->LRU_old_len
      even if buf_pool->LRU_old is NULL.  Check that bpage->old is monotonic.
      
      buf_relocate(): Make the UNIV_LRU_DEBUG checks stricter.
      
      buf0buf.h: Revise the documentation of buf_page_t::old and
      buf_pool_t::LRU_old_len.
      aa14038f