An error occurred fetching the project authors.
  1. 03 Oct, 2008 1 commit
  2. 11 Aug, 2008 1 commit
    • Mattias Jonsson's avatar
      Bug#20129: ALTER TABLE ... REPAIR PARTITION ... complains that · 07e9a6dc
      Mattias Jonsson authored
      partition is corrupt
      
      The main problem was that ALTER TABLE t ANALYZE/CHECK/OPTIMIZE/REPAIR
      PARTITION took another code path (over mysql_alter_table instead of
      mysql_admin_table) which differs in two ways:
      1) alter table opens the tables in a different way than admin tables do
         resulting in returning with error before it tried the command
      2) alter table does not start to send any diagnostic rows to the client
         which the lower admin functions continue to use -> resulting in
         assertion crash
      
      The fix:
      Remapped ALTER TABLE t ANALYZE/CHECK/OPTIMIZE/REPAIR PARTITION to use
      the same code path as ANALYZE/CHECK/OPTIMIZE/REPAIR TABLE t.
      Adding check in mysql_admin_table to setup the partition list for
      which partitions that should be used.
      
      
      Partitioned tables will still not work with
      REPAIR TABLE/PARTITION USE_FRM, since that requires moving partitions
      to tables, REPAIR TABLE t USE_FRM, and check that the data still
      fulfills the partitioning function and then move the table back to
      being a partition.
      
      NOTE: I have removed the following functions from the handler
      interface:
      analyze_partitions, check_partitions, optimize_partitions,
      repair_partitions
      Since they are not longer needed.
      THIS ALTERS THE STORAGE ENGINE API
      07e9a6dc
  3. 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
  4. 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
  5. 17 Jun, 2008 1 commit
  6. 07 May, 2008 1 commit
  7. 29 Apr, 2008 1 commit
  8. 15 Feb, 2008 1 commit
  9. 07 Feb, 2008 1 commit
  10. 11 Jan, 2008 1 commit
    • igor@olga.mysql.com's avatar
      Fixed bug #33697. · b85ffdb5
      igor@olga.mysql.com authored
      When the function test_if_skip_sort_order prefers index backward scan 
      to ref access the corresponding access functions must be set accordingly.
      b85ffdb5
  11. 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
  12. 30 Nov, 2007 1 commit
    • tnurnberg@mysql.com/white.intern.koehntopp.de's avatar
      Bug#31177: Server variables can't be set to their current values · 31d4e58a
      Default values of variables were not subject to upper/lower bounds
      and step, while setting variables was. Bounds and step are also
      applied to defaults now; defaults are corrected quietly, values
      given by the user are corrected, and a correction-warning is thrown
      as needed. Lastly, very large values could wrap around, starting
      from 0 again. They are bounded at the maximum value for the
      respective data-type now if no lower maximum is specified in the
      variable's definition.
      31d4e58a
  13. 27 Nov, 2007 1 commit
  14. 07 Nov, 2007 1 commit
  15. 02 Nov, 2007 1 commit
  16. 29 Oct, 2007 2 commits
  17. 26 Oct, 2007 1 commit
  18. 08 Oct, 2007 2 commits
    • gshchepa/uchum@gleb.loc's avatar
      Fixed bug #31310. · 09f6306a
      gshchepa/uchum@gleb.loc authored
      Locked rows of the InnoDB storage was silently skipped in the read-committed
      isolation level.
      
      QUICK_RANGE_SELECT for unique ranges lacks second (blocking) read
      of the record that was read semi-consistently and just skip it.
      
      The handler::read_multi_range_next method has been modified
      to retry previous unique range if the previous read was
      semi-consistent.
      09f6306a
    • 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
  19. 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
  20. 14 Sep, 2007 2 commits
    • 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
    • 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
  21. 13 Sep, 2007 1 commit
    • davi@moksha.local's avatar
      Bug#30747 Create table with identical constraint names behaves incorrectly · 2a70d6fa
      davi@moksha.local authored
      MySQL provides what appears to be a non standard extension to the
      FOREIGN KEY syntax which let users name (label/tag) a foreign key
      to more easily identify a specific foreign key if any problems show
      up later during the query parsing or execution. But the foreign key
      name was not being properly set to the right key, possible leaving
      the foreign key with no name.
      2a70d6fa
  22. 28 Aug, 2007 1 commit
    • mhansson/martin@linux-st28.site's avatar
      Bug #30596 GROUP BY optimization gives wrong result order · 98d34d62
      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 implied by GROUP BY.
      Fixed by replacing GROUP BY with ORDER BY if the GROUP BY clause contains
      a unique index over non-nullable field(s). In case GROUP BY ... ORDER BY 
      null is used, GROUP BY is simply removed.
      98d34d62
  23. 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
  24. 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
  25. 04 Aug, 2007 1 commit
  26. 02 Aug, 2007 1 commit
    • igor@olga.mysql.com's avatar
      Fixed bug#28404. · cf394292
      igor@olga.mysql.com authored
      This patch adds cost estimation for the queries with ORDER BY / GROUP BY
      and LIMIT. 
      If there was a ref/range access to the table whose rows were required
      to be ordered in the result set the optimizer always employed this access
      though a scan by a different index that was compatible with the required 
      order could be cheaper to produce the first L rows of the result set.
      Now for such queries the optimizer makes a choice between the cheapest
      ref/range accesses not compatible with the given order and index scans
      compatible with it.
      cf394292
  27. 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
  28. 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
  29. 18 Jul, 2007 1 commit
  30. 16 Jul, 2007 2 commits
  31. 15 Jul, 2007 1 commit
  32. 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
  33. 04 Jul, 2007 1 commit