An error occurred fetching the project authors.
  1. 26 Feb, 2010 1 commit
    • Evgeny Potemkin's avatar
      Bug#50843: Filesort used instead of clustered index led to · cc01fc3f
      Evgeny Potemkin authored
      performance degradation.
      
      Filesort + join cache combination is preferred to full index scan because it
      is usually faster. But it's not the case when the index is clustered one.
      
      Now test_if_skip_sort_order function prefers filesort only if index isn't
      clustered.
      cc01fc3f
  2. 29 Jan, 2010 1 commit
    • Georgi Kodinov's avatar
      Bug #49324: more valgrind errors in test_if_skip_sort_order · f11861c2
      Georgi Kodinov authored
      Fixed 2 problems :
      1. test_if_order_by_key() was continuing on the primary key
      as if it has a primary key suffix (as the secondary keys do).
      This leads to crashes in ORDER BY <pk>,<pk>.
      Fixed by not treating the primary key as the secondary one
      and not depending on it being clustered with a primary key.
      2. The cost calculation was trying to read the records 
      per key when operating on ORDER BYs that order on all of the 
      secondary key + some of the primary key.
      This leads to crashes because of out-of-bounds array access.
      Fixed by assuming we'll find 1 record per key in such cases.
      f11861c2
  3. 01 Dec, 2009 1 commit
  4. 30 Nov, 2009 1 commit
    • Magne Mahre's avatar
      Bug #20837 Apparent change of isolation level during transaction · 8c24f5d1
      Magne Mahre authored
            
      SET TRANSACTION ISOLATION LEVEL is used to temporarily set
      the trans.iso.level for the next transaction.  After the
      transaction, the iso.level is (re-)set to value of the 
      session variable 'tx_isolation'.
      
      The bug is caused by setting the thd->variables.tx_isolation 
      field to the value of the session variable upon each
      statement commit.  It should only be set at the end of the
      full transaction.
      
      The fix has been to remove the setting of the variable in
      ha_autocommit_or_rollback if we're in a transaction, as it 
      will be correctly set in  either ha_rollback or 
      ha_commit_one_phase.  
      
      If, on the other hand, we're in  autocommit mode, tx_isolation 
      will be explicitly set here.
      8c24f5d1
  5. 25 Nov, 2009 1 commit
    • MySQL Build Team's avatar
      Backport into build-200911241145-5.1.40sp1 · cf3dc5b0
      MySQL Build Team authored
      > ------------------------------------------------------------
      > revno: 3182 [merge]
      > revision-id: ramil@mysql.com-20091018162655-z4dlolfx5s0zem8l
      > parent: alexey.kopytov@sun.com-20091016201951-fsht0wm8xn8vkzsx
      > parent: ramil@mysql.com-20091013044327-24km05wc060ied87
      > committer: Ramil Kalimullin <ramil@mysql.com>
      > branch nick: mysql-5.1-bugteam
      > timestamp: Sun 2009-10-18 21:26:55 +0500
      > message:
      >   Fix for bug#47963: Wrong results when index is used
      >   
      >   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.
      > ------------------------------------------------------------
      > Use --include-merges or -n0 to see merged revisions.
      cf3dc5b0
  6. 04 Nov, 2009 1 commit
    • 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
  7. 13 Oct, 2009 1 commit
    • Ramil Kalimullin's avatar
      Fix for bug#47963: Wrong results when index is used · 5a23617a
      Ramil Kalimullin authored
      Problem: using null microsecond part (e.g. "YYYY-MM-DD HH:MM:SS.0000") 
      in a WHERE condition may lead to wrong results due to improper
      DATETIMEs comparison in some cases.
      
      Fix: as we compare DATETIMEs as strings we must trim trailing 0's
      in such cases.
      5a23617a
  8. 07 Jul, 2009 1 commit
    • Georgi Kodinov's avatar
      Bug #36259 (Optimizing with ORDER BY) and bug#45828 (Optimizer won't · d9e82ba8
      Georgi Kodinov authored
      use partial primary key if another index can prevent filesort
      
      The fix for bug #28404 causes the covering ordering indexes to be 
      preferred unconditionally over non-covering and ref indexes.
      
      Fixed by comparing the cost of using a covering index to the cost of
      using a ref index even for covering ordering indexes.
      Added an assertion to clarify the condition the local variables should
      be in.
      d9e82ba8
  9. 07 Jun, 2009 1 commit
  10. 04 Jun, 2009 1 commit
  11. 19 May, 2009 1 commit
  12. 05 May, 2009 1 commit
    • Martin Hansson's avatar
      Bug#43580: Issue with Innodb on multi-table update · 2afccc1b
      Martin Hansson authored
                              
      Certain multi-updates gave different results on InnoDB from
      to MyISAM, due to on-the-fly updates being used on the former and
      the update order matters.
      Fixed by turning off on-the-fly updates when update order 
      dependencies are present.
      2afccc1b
  13. 30 Apr, 2009 1 commit
  14. 27 Mar, 2009 2 commits
    • Kristofer Pettersson's avatar
      Bug#40127 Multiple table DELETE IGNORE hangs on foreign key constraint violation · 137f1e1e
      Kristofer Pettersson authored
                on 5.0            
      The server crashes on an assert in net_end_statement indicating that the
      Diagnostics area wasn't set properly during execution.
      This happened on a multi table DELETE operation using the IGNORE keyword.
      The keyword is suppose to allow for execution to continue on a best effort
      despite some non-fatal errors. Instead execution stopped and no client
      response was sent which would have led to a protocol error if it hadn't been
      for the assert.
      This patch corrects this issue by checking for the existence of an IGNORE
      option before setting an error state during row-by-row delete iteration.
      137f1e1e
    • Ramil Kalimullin's avatar
      Fix for bug #26288: savepoint not deleted, comit on empty transaction · 2005f3c7
      Ramil Kalimullin authored
      Problem: commit doesn't delete savepoints if there are no changes 
      in the transaction.
      
      Fix: delete them in such cases.
      2005f3c7
  15. 20 Feb, 2009 1 commit
    • Georgi Kodinov's avatar
      Bug #42419: test suite fix · 39dc3623
      Georgi Kodinov authored
      Moved the test case for the bug into a separate file (and restored the 
      original innodb_mysql test setup).
      Used the new wait_show_condition test macro to avoid the usage of sleep
      39dc3623
  16. 19 Feb, 2009 1 commit
    • Georgi Kodinov's avatar
      Bug #42419: Server crash with "Pure virtual method called" on two concurrent · b2c161c1
      Georgi Kodinov authored
      connections
      The problem is that tables can enter open table cache for a thread without 
      being properly cleaned up. This can happen if make_join_statistics() fails 
      to read a const table because of e.g. a deadlock. It does set a member of 
      TABLE structure to a value it allocates, but doesn't clean-up this setting 
      on error nor does it set the rest of the members in JOIN to allow for 
      automatic cleanup.
      As a result when such an error occurs and the next statement depends re-uses 
      the table from the open tables cache it will get it with this 
      TABLE::reginfo.join_tab pointing to a memory area that's freed.
      Fixed by making sure make_join_statistics() cleans up TABLE::reginfo.join_tab 
      on error.
      b2c161c1
  17. 09 Jan, 2009 1 commit
    • Davi Arnaut's avatar
      Bug#37016: TRUNCATE TABLE removes some rows but not all · 577e390e
      Davi Arnaut authored
      The special TRUNCATE TABLE (DDL) transaction wasn't being properly
      rolled back if a error occurred during row by row deletion. The
      error can be caused by a foreign key restriction imposed by InnoDB
      SE and would cause the server to erroneously issue a implicit
      commit.
      
      The solution is to rollback the transaction if a truncation via row
      by row deletion fails, otherwise commit. All effects of a TRUNCATE 
      ABLE operation are rolled back if a row by row deletion fails.
      577e390e
  18. 07 Jan, 2009 1 commit
    • Davi Arnaut's avatar
      Bug#41348: INSERT INTO tbl SELECT * FROM temp_tbl overwrites · dc5a0f44
      Davi Arnaut authored
                 locking type of temp table
      
      The problem is that INSERT INTO .. SELECT FROM .. and CREATE
      TABLE .. SELECT FROM a temporary table could inadvertently
      overwrite the locking type of the temporary table. The lock
      type of temporary tables should be a write lock by default.
      
      The solution is to reset the lock type of temporary tables
      back to its default value after they are used in a statement.
      dc5a0f44
  19. 29 Nov, 2008 1 commit
    • Georgi Kodinov's avatar
      Bug #37742: HA_EXTRA_KEYREAD flag is set when key contains only prefix of requested · f486bfbb
      Georgi Kodinov authored
      column
            
      When the storage engine uses secondary keys clustered with the primary key MySQL was
      adding the primary key parts to each secondary key.
      In doing so it was not checking whether the index was on full columns and this
      resulted in the secondary keys being added to the list of covering keys even if 
      they have partial columns.
      Fixed by not adding a primary key part to the list of columns that can be used 
      for index read of the secondary keys when the primary key part is a partial key part.
      f486bfbb
  20. 27 Nov, 2008 1 commit
    • Sergey Glukhov's avatar
      Bug#37284 Crash in Field_string::type() · 63bca358
      Sergey Glukhov authored
      The bug is repeatable with latest(1.0.1) InnoDB plugin on Linux, Win,
      If MySQL is compiled with valgrind there are errors about
      using of uninitialized variable(orig_table).
      The fix is to set field->orig_table correct value.
      63bca358
  21. 03 Nov, 2008 2 commits
    • Mats Kindahl's avatar
      Bug #40360: Binlog related errors with binlog off · 32c9fe6b
      Mats Kindahl authored
      Adding missing drop of created table and tidying display.
      32c9fe6b
    • Mats Kindahl's avatar
      Bug #40360: Binlog related errors with binlog off · 005e7fc3
      Mats Kindahl authored
            
      When statement-based replication is used, and the
      transaction isolation level is READ-COMMITTED or stricter,
      InnoDB will print an error because statement-based
      replication might lead to inconsistency between master
      and slave databases. However, when the binary log is not
      engaged, this is not an issue and an error should
      not be printed.
      
      This patch makes thd_binlog_format() return BINLOG_FORMAT_
      UNSPEC when the binary log is not engaged for the given
      thread.
      005e7fc3
  22. 23 Jul, 2008 1 commit
    • Georgi Kodinov's avatar
      Bug#37830 : ORDER BY ASC/DESC - no difference · 436f1dc4
      Georgi Kodinov authored
                        
      Range scan in descending order for c <= <col> <= c type of
      ranges was ignoring the DESC flag.
      However some engines like InnoDB have the primary key parts 
      as a suffix for every secondary key.
      When such primary key suffix is used for ordering ignoring 
      the DESC is not valid.
      But we generally would like to do this because it's faster.
                  
      Fixed by performing only reverse scan if the primary key is used.
      Removed some dead code in the process.
      436f1dc4
  23. 16 Jul, 2008 1 commit
    • Georgi Kodinov's avatar
      Bug#37830 : ORDER BY ASC/DESC - no difference · 59ab9a08
      Georgi Kodinov authored
                  
      Range scan in descending order for c <= <col> <= c type of
      ranges was ignoring the DESC flag.
      However some engines like InnoDB have the primary key parts 
      as a suffix for every secondary key.
      When such primary key suffix is used for ordering ignoring 
      the DESC is not valid.
      But we generally would like to do this because it's faster.
            
      Fixed by performing only reverse scan if the primary key is used.
      Removed some dead code in the process.
      59ab9a08
  24. 07 May, 2008 1 commit
  25. 07 Feb, 2008 1 commit
  26. 08 Dec, 2007 1 commit
    • igor@olga.mysql.com's avatar
      Fixed bug #32815. · c394dbe1
      igor@olga.mysql.com authored
      The index (key_part_1, key_part-2) was erroneously considered as compatible
      with the required ordering in the function test_test_if_order_by_key when 
      a query with an ORDER BY clause contained a condition of the form
        key_part_1=const OR key_part_1 IS NULL 
      and the order list contained only key_part_2. This happened because the value
      of the const_key_parts field in the KEYUSE structure was not formed correctly
      for the keys that could be used for ref_or_null access. 
      This was fixed in the code of the update_ref_and_keys function.
      The problem could not manifest itself for MyISAM databases because the
      implementation of the keys_to_use_for_scanning() handler function always
      returns an empty bitmap for the MyISAM engine.
      c394dbe1
  27. 26 Oct, 2007 1 commit
  28. 08 Oct, 2007 1 commit
    • serg@janus.mylan's avatar
      sql_plugin.cc: · 55f7f3ef
      serg@janus.mylan authored
        fixed uninit memory access in SET pluginvar=DEFAULT
      innodb_mysql.test, innodb_mysql.result:
        test case for SET pluginvar=DEFAULT
      55f7f3ef
  29. 04 Oct, 2007 1 commit
    • kaa@polly.(none)'s avatar
      Backport of the 5.0 patch to 4.1 · f74d805e
      kaa@polly.(none) authored
      Bug#28878: InnoDB tables with UTF8 character set and indexes cause  wrong result for DML
      When making key reference buffers over CHAR fields whitespace (0x20) must be used to fill in the remaining space in the field's buffer. This is what Field_string::store() does. Fixed Field_string::get_key_image() to do the same.
      f74d805e
  30. 14 Sep, 2007 1 commit
    • gkodinov/kgeorge@magare.gmz's avatar
      Bug #31001: ORDER BY DESC in InnoDB not working · a2afc56f
      gkodinov/kgeorge@magare.gmz authored
      The optimizer sets index traversal in reverse order only if there are 
       used key parts that are not compared to a constant.
      However using the primary key as an ORDER BY suffix rendered the check
      incomplete : going in reverse order must still be used even if 
      all the parts of the secondary key are compared to a constant.
      
      Fixed by relaxing the check and set reverse traversal even when all
      the secondary index keyparts are compared to a const.
      Also account for the case when all the primary keys are compared to a
      constant.
      a2afc56f
  31. 27 Aug, 2007 1 commit
    • mhansson/martin@linux-st28.site's avatar
      Bug #30596 GROUP BY optimization gives wrong result order · a4d5d920
      mhansson/martin@linux-st28.site authored
      The optimization that uses a unique index to remove GROUP BY, did not 
      ensure that the index was actually used, thus violating the ORDER BY
      that is impled by GROUP BY.
      Fixed by replacing GROUP BY with ORDER BY if the GROUP BY clause contains
      a unique index. In case GROUP BY ... ORDER BY null is used, GROUP BY is
      simply removed.
      a4d5d920
  32. 15 Aug, 2007 1 commit
    • mhansson/martin@linux-st28.site's avatar
      bug#28570: handler::index_read() is called with different find_flag when · 1da8451d
      mhansson/martin@linux-st28.site authored
      ORDER BY is used
      
      The range analysis module did not correctly signal to the 
      handler that a range represents a ref (EQ_RANGE flag). This causes 
      non-range queries like 
      SELECT ... FROM ... WHERE keypart_1=const, ..., keypart_n=const 
      ORDER BY ... FOR UPDATE
      to wait for a lock unneccesarily if another running transaction uses
      SELECT ... FOR UPDATE on the same table.
      
      Fixed by setting EQ_RANGE for all range accesses that represent 
      an equality predicate. 
      1da8451d
  33. 27 Jul, 2007 1 commit
    • kostja@bodhi.(none)'s avatar
      A fix and a test case for Bug#24918 drop table and lock / inconsistent · 11c57540
      kostja@bodhi.(none) authored
      between perm and temp tables. Review fixes.
      
      The original bug report complains that if we locked a temporary table
      with LOCK TABLES statement, we would not leave LOCK TABLES mode
      when this temporary table is dropped.
      
      Additionally, the bug was escalated when it was discovered than
      when a temporary transactional table that was previously
      locked with LOCK TABLES statement was dropped, futher actions with
      this table, such as UNLOCK TABLES, would lead to a crash.
      
      The problem originates from incomplete support of transactional temporary
      tables. When we added calls to handler::store_lock()/handler::external_lock()
      to operations that work with such tables, we only covered the normal
      server code flow and did not cover LOCK TABLES mode. 
      In LOCK TABLES mode, ::external_lock(LOCK) would sometimes be called without
      matching ::external_lock(UNLOCK), e.g. when a transactional temporary table
      was dropped. Additionally, this table would be left in the list of LOCKed 
      TABLES.
      
      The patch aims to address this inadequacy. Now, whenever an instance
      of 'handler' is destroyed, we assert that it was priorly
      external_lock(UNLOCK)-ed. All the places that violate this assert
      were fixed.
      
      This patch introduces no changes in behavior -- the discrepancy in
      behavior will be fixed when we start calling ::store_lock()/::external_lock()
      for all tables, regardless whether they are transactional or not, 
      temporary or not.
      11c57540
  34. 20 Jul, 2007 2 commits
    • gkodinov/kgeorge@magare.gmz's avatar
      Bug #28591: MySQL need not sort the records in case of · 8fc401e2
      gkodinov/kgeorge@magare.gmz authored
      ORDER BY primary_key on InnoDB table
      
      Queries that use an InnoDB secondary index to retrieve
      data don't need to sort in case of ORDER BY primary key
      if the secondary index is compared to constant(s).
      They can also skip sorting if ORDER BY contains both the
      the secondary key parts and the primary key parts (in
      that order).
      This is because InnoDB returns the rows in order of the
      primary key for rows with the same values of the secondary
      key columns.
      Fixed by preventing temp table sort for the qualifying 
      queries.
      8fc401e2
    • gkodinov/kgeorge@magare.gmz's avatar
      Bug #29644: alter table hangs if records locked in share mode · 174dcb07
      gkodinov/kgeorge@magare.gmz authored
      by long running transaction
      
      On Windows opened files can't be deleted. There was a special
      upgraded lock mode (TL_WRITE instead of TL_WRITE_ALLOW_READ) 
      in ALTER TABLE to make sure nobody has the table opened
      when deleting the old table in ALTER TABLE. This special mode
      was causing ALTER TABLE to hang waiting on a lock inside InnoDB.
      This special lock is no longer necessary as the server is 
      closing the tables it needs to delete in ALTER TABLE.
      Fixed by removing the special lock.
      Note that this also reverses the fix for bug 17264 that deals with
      another consequence of this special lock mode being used.
      174dcb07
  35. 18 Jul, 2007 1 commit
  36. 15 Jul, 2007 1 commit
  37. 02 Jul, 2007 1 commit