An error occurred fetching the project authors.
  1. 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
  2. 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
  3. 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
  4. 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
  5. 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
  6. 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
  7. 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
  8. 07 May, 2008 1 commit
  9. 07 Feb, 2008 1 commit
  10. 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
  11. 26 Oct, 2007 1 commit
  12. 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
  13. 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
  14. 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
  15. 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
  16. 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
  17. 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
  18. 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
  19. 18 Jul, 2007 1 commit
  20. 15 Jul, 2007 1 commit
  21. 02 Jul, 2007 1 commit
  22. 01 Jul, 2007 1 commit
    • igor@olga.mysql.com's avatar
      Fixed bug #25798. · f8683bfb
      igor@olga.mysql.com authored
      This bug may manifest itself not only with the queries for which
      the index-merge access method is chosen. It also may display
      itself for queries with DISTINCT.
      
      The bug was in how the Unique::get method used the merge_buffers
      function. To compare elements in the the queue employed by
      merge_buffers() it must use the buffpek_compare function rather
      than the function for binary comparison. 
      f8683bfb
  23. 25 Jun, 2007 1 commit
    • gkodinov/kgeorge@magare.gmz's avatar
      Bug #29154: LOCK TABLES is not atomic when >1 InnoDB tables are locked · f93607d2
      gkodinov/kgeorge@magare.gmz authored
        LOCK TABLES takes a list of tables to lock. It may lock several 
        tables successfully and then encounter a tables that it can't lock, 
        e.g. because it's locked. In such case it needs to undo the locks on
        the already locked tables. And it does that. But it has also notified
        the relevant table storage engine handlers that they should lock.
        The only reliable way to ensure that the table handlers will give up
        their locks is to end the transaction. This is what UNLOCK TABLE 
        does : it ends the transaction if there were locked tables by LOCK 
        tables.
        It is possible to end the transaction when the lock fails in 
        LOCK TABLES because LOCK TABLES ends the transaction at its start 
        already. 
        Fixed by ending (again) the transaction when LOCK TABLES fails to
        lock a table.
      f93607d2
  24. 20 Jun, 2007 1 commit
  25. 07 Jun, 2007 1 commit
  26. 01 Jun, 2007 1 commit
  27. 15 May, 2007 1 commit
  28. 10 May, 2007 1 commit
  29. 28 Apr, 2007 1 commit
    • gshchepa/uchum@gshchepa.loc's avatar
      Fixed bug #13191. · 3adcb94e
      gshchepa/uchum@gshchepa.loc authored
      INSERT...ON DUPLICATE KEY UPDATE may cause error 1032: 
      "Can't find record in ..." if we are inserting into
      InnoDB table unique index of partial key with
      underlying UTF-8 string field.
      
      This error occurs because INSERT...ON DUPLICATE uses a wrong
      procedure to copy string fields of multi-byte character sets
      for index search.
      3adcb94e
  30. 25 Apr, 2007 1 commit
    • gshchepa/uchum@gshchepa.loc's avatar
      Fixed bug #27650: · 5983038a
      gshchepa/uchum@gshchepa.loc authored
      INSERT into InnoDB table may cause "ERROR 1062 (23000): Duplicate entry..."
      errors or lost records after multi-row INSERT of the form:
      "INSERT INTO t (id...) VALUES (NULL...) ON DUPLICATE KEY UPDATE id=VALUES(id)",
      where "id" is an AUTO_INCREMENT column.
      
      It happens because InnoDB handler forgets to save next insert id after
      updating of auto_increment column with new values. As result of that
      last insert id stored inside InnoDB dictionary tables differs from it's
      cached thd->next_insert_id value.
      5983038a
  31. 19 Apr, 2007 2 commits
  32. 11 Feb, 2007 1 commit
    • igor@olga.mysql.com's avatar
      Fixed bug #26159. · 976e747a
      igor@olga.mysql.com authored
      A wrong order of statements in QUICK_GROUP_MIN_MAX_SELECT::reset
      caused a crash when a query with DISTINCT was executed by a loose scan
      for an InnoDB table that had been emptied. 
      976e747a
  33. 19 Dec, 2006 1 commit
  34. 30 Oct, 2006 1 commit
  35. 25 Oct, 2006 1 commit
    • kroki/tomash@moonlight.intranet's avatar
      BUG#18819: DELETE IGNORE hangs on foreign key parent delete · b7b991ce
      kroki/tomash@moonlight.intranet authored
      If the error happens during DELETE IGNORE, nothing could be send to the
      client, thus leaving it frozen expecting the reply.
      
      The problem was that if some error occurred, it wouldn't be reported to
      the client because of IGNORE, but neither success would be reported.
      
      MySQL 4.1 would not freeze the client, but will report
      
        ERROR 1105 (HY000): Unknown error
      
      instead, which is also a bug.
      
      The solution is to report success if we are in DELETE IGNORE and some
      non-fatal error has happened.
      b7b991ce
  36. 11 Oct, 2006 1 commit
  37. 09 Oct, 2006 1 commit
    • gkodinov/kgeorge@macbook.local's avatar
      Bug #22781: SQL_BIG_RESULT fails to influence sort plan · 13633864
      gkodinov/kgeorge@macbook.local authored
       Currently SQL_BIG_RESULT is checked only at compile time.
       However, additional optimizations may take place after
       this check that change the sort method from 'filesort'
       to sorting via index. As a result the actual plan
       executed is not the one specified by the SQL_BIG_RESULT
       hint. Similarly, there is no such test when executing
       EXPLAIN, resulting in incorrect output.
       The patch corrects the problem by testing for
       SQL_BIG_RESULT both during the explain and execution
       phases.
      13633864