An error occurred fetching the project authors.
  1. 14 Sep, 2007 1 commit
    • gkodinov/kgeorge@magare.gmz's avatar
      Bug #31001: ORDER BY DESC in InnoDB not working · dc028202
      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.
      dc028202
  2. 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
  3. 20 Jul, 2007 4 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
    • ramil/ram@mysql.com/ramil.myoffice.izhnet.ru's avatar
      4a2a1315
    • ramil/ram@mysql.com/ramil.myoffice.izhnet.ru's avatar
      8e22343c
  4. 18 Jul, 2007 1 commit
  5. 16 Jul, 2007 2 commits
  6. 15 Jul, 2007 1 commit
  7. 08 Jul, 2007 1 commit
    • evgen@moonbone.local's avatar
      Bug#29310: An InnoDB table was updated when the data wasn't actually changed. · 42d1e3c4
      evgen@moonbone.local authored
      When a table is being updated it has two set of fields - fields required for
      checks of conditions and fields to be updated. A storage engine is allowed
      not to retrieve columns marked for update. Due to this fact records can't
      be compared to see whether the data has been changed or not. This makes the
      server always update records independently of data change.
      
      Now when an auto-updatable timestamp field is present and server sees that
      a table handle isn't going to retrieve write-only fields then all of such
      fields are marked as to be read to force the handler to retrieve them.
      42d1e3c4
  8. 04 Jul, 2007 1 commit
  9. 02 Jul, 2007 1 commit
  10. 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
  11. 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
  12. 20 Jun, 2007 1 commit
  13. 07 Jun, 2007 1 commit
  14. 04 Jun, 2007 1 commit
  15. 01 Jun, 2007 1 commit
  16. 29 May, 2007 1 commit
  17. 19 May, 2007 1 commit
    • dlenev@mockturtle.local's avatar
      Patch changing how ALTER TABLE implementation handles table locking · b0dfdc2b
      dlenev@mockturtle.local authored
      and invalidation in the most general case (non-temporary table and
      not simple RENAME or ENABLE/DISABLE KEYS or partitioning command).
      
      See comment for sql/sql_table.cc for more information.
      
      These changes are prerequisite for 5.1 version of fix for bug #23667
      "CREATE TABLE LIKE is not isolated from alteration by other connections"
      b0dfdc2b
  18. 15 May, 2007 1 commit
  19. 14 May, 2007 1 commit
    • dlenev@mockturtle.local's avatar
      Fix for bug #28415 "Some ALTER TABLE statements no longer work under LOCK · d748e4de
      dlenev@mockturtle.local authored
      TABLES" and failures of alter_table.test on Windows which occured after
      pushing fix for bugs #20662, #20903, #24508, #24738 (various problems
      with CREATE TABLE SELECT).
      
      ALTER TABLE statements which were handled using "fast" alter table
      optimization were not properly working under LOCK TABLES if table
      was transactional (for all table types under Windows).
      
      Code implementing "fast" version of ALTER TABLE tried to open and
      lock table using open_ltable() after renaming .FRM files (which
      corresponds to renaming tables in normal case) in some cases
      (for transactional tables or on Windows). This caused problems
      under LOCK TABLES and conflicted with name-lock taken by 
      ALTER TABLE RENAME on target tables.
      
      This patch solves this issue by using reopen_name_locked_table()
      instead of open_ltable().
      d748e4de
  20. 10 May, 2007 1 commit
  21. 04 May, 2007 1 commit
    • gkodinov/kgeorge@magare.gmz's avatar
      bug #27531: 5.1 part of the fix: · 306371a8
      gkodinov/kgeorge@magare.gmz authored
       - added join cache indication in EXPLAIN (Extra column).
       - prefer filesort over full scan over 
         index for ORDER BY (because it's faster).
       - when switching from REF to RANGE because
         RANGE uses longer key turn off sort on
         the head table only as the resulting 
         RANGE access is a candidate for join cache
         and we don't want to disable it by sorting
         on the first table only. 
      306371a8
  22. 29 Apr, 2007 2 commits
  23. 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
  24. 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
  25. 19 Apr, 2007 2 commits
  26. 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
  27. 19 Dec, 2006 1 commit
  28. 30 Oct, 2006 1 commit
  29. 25 Oct, 2006 3 commits
  30. 11 Oct, 2006 1 commit
  31. 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
  32. 28 Sep, 2006 1 commit