An error occurred fetching the project authors.
  1. 24 Mar, 2010 1 commit
  2. 17 Mar, 2010 1 commit
    • Mattias Jonsson's avatar
      Bug#50561: ALTER PARTITIONS does not have adequate lock, breaks with · 3b897f2b
      Mattias Jonsson authored
      concurrent I_S query
      
      There were two problem:
      1) MYSQL_LOCK_IGNORE_FLUSH also ignored name locks
      2) there was a race between abort_and_upgrade_locks and
         alter_close_tables
         (i.e. remove_table_from_cache and
          close_data_files_and_morph_locks)
      
      Which allowed the table to be opened with MYSQL_LOCK_IGNORE_FLUSH flag
      resulting in renaming a partition that was already in use,
      which could cause the table to be unusable.
      
      Solution was to not allow IGNORE_FLUSH to skip waiting for
      a named locked table.
      
      And to not release the LOCK_open mutex between the
      calls to remove_table_from_cache and
      close_data_files_and_morph_locks by merging the functions
      abort_and_upgrade_locks and alter_close_tables.
      3b897f2b
  3. 10 Mar, 2010 1 commit
    • Mattias Jonsson's avatar
      Bug#51830: Incorrect partition pruning on range partition · f83e302a
      Mattias Jonsson authored
      (regression)
      
      Problem was that partition pruning did not exclude the
      last partition if the range was beyond it
      (i.e. not using MAXVALUE)
      
      Fix was to not include the last partition if the
      partitioning function value was not within the partition
      range.
      f83e302a
  4. 04 Mar, 2010 1 commit
  5. 24 Jan, 2010 1 commit
  6. 18 Jan, 2010 1 commit
    • Mattias Jonsson's avatar
      Bug#47343: InnoDB fails to clean-up after lock wait timeout on · b1987bdc
      Mattias Jonsson authored
                 REORGANIZE PARTITION
      
      There were several problems which lead to this this,
      all related to bad error handling.
      
      1) There was several bugs preventing the ddl-log to be used for
         cleaning up created files on error.
      
      2) The error handling after the copy partition rows did not close
         and unlock the tables, resulting in deletion of partitions
         which were in use, which lead InnoDB to put the partition to
         drop in a background queue.
      b1987bdc
  7. 22 Dec, 2009 1 commit
  8. 13 Dec, 2009 1 commit
    • Alexey Kopytov's avatar
      Bug #42849: innodb crash with varying time_zone on partitioned · a8cfe3d4
      Alexey Kopytov authored
                  timestamp primary key 
       
      Since TIMESTAMP values are adjusted by the current time zone  
      settings in both numeric and string contexts, using any 
      expressions involving TIMESTAMP values as a  
      (sub)partitioning function leads to undeterministic behavior of  
      partitioned tables. The effect may vary depending on a storage  
      engine, it can be either incorrect data being retrieved or  
      stored, or an assertion failure. The root cause of this is the  
      fact that the calculated partition ID may differ from a  
      previously calculated ID for the same data due to timezone  
      adjustments of the partitioning expression value. 
       
      Fixed by disabling any expressions involving TIMESTAMP values  
      to be used in partitioning functions with the follwing two 
      exceptions: 
       
      1. Creating or altering into a partitioned table that violates 
      the above rule is not allowed, but opening existing such tables 
      results in a warning rather than an error so that such tables 
      could be fixed. 
       
      2. UNIX_TIMESTAMP() is the only way to get a 
      timezone-independent value from a TIMESTAMP column, because it 
      returns the internal representation (a time_t value) of a 
      TIMESTAMP argument verbatim. So UNIX_TIMESTAMP(timestamp_column)
      is allowed and should be used to fix existing tables if one 
      wants to use TIMESTAMP columns with partitioning.
      a8cfe3d4
  9. 17 Nov, 2009 1 commit
  10. 09 Nov, 2009 1 commit
  11. 03 Nov, 2009 1 commit
    • Mattias Jonsson's avatar
      Bug#46923: select count(*) from partitioned table fails with · 8a2ca22a
      Mattias Jonsson authored
      ONLY_FULL_GROUP_BY
      
      Problem was that during checking and preparation of the
      partitioining function as a side effect in fix_fields
      the full_group_by_flag was changed.
      
      Solution was to set it back to its original value after
      calling fix_fields.
      
      Updated patch, to also exclude allow_sum_func from being
      affected of fix_fields, as requested by reviewer.
      8a2ca22a
  12. 16 Oct, 2009 1 commit
    • Georgi Kodinov's avatar
      Bug #40877: multi statement execution fails in 5.1.30 · 8f6f3dba
      Georgi Kodinov authored
            
      Implemented the server infrastructure for the fix:
      
      1. Added a function LEX_STRING *thd_query_string(THD) to return
      a LEX_STRING structure instead of char *.
      This is the function that must be called in innodb instead of 
      thd_query()
      
      2. Did some encapsulation in THD : aggregated thd_query and 
      thd_query_length into a LEX_STRING and made accessor and mutator 
      methods for easy code updating. 
      
      3. Updated the server code to use the new methods where applicable.
      8f6f3dba
  13. 23 Sep, 2009 1 commit
  14. 02 Sep, 2009 1 commit
  15. 26 Aug, 2009 1 commit
    • Mattias Jonsson's avatar
      Bug#20577: Partitions: use of to_days() function leads to selection failures · 401fb7c6
      Mattias Jonsson authored
      Problem was that the partition containing NULL values
      was pruned away, since '2001-01-01' < '2001-02-00' but
      TO_DAYS('2001-02-00') is NULL.
      
      Added the NULL partition for RANGE/LIST partitioning on TO_DAYS()
      function to be scanned too.
      
      Also fixed a bug that added ALLOW_INVALID_DATES to sql_mode
      (SELECT * FROM t WHERE date_col < '1999-99-99' on a RANGE/LIST
      partitioned table would add it).
      401fb7c6
  16. 06 Aug, 2009 1 commit
    • Mattias Jonsson's avatar
      Bug#46478: timestamp field incorrectly defaulted · 89b9fbd4
      Mattias Jonsson authored
      when partition is reoganized.
      
      Problem was that table->timestamp_field_type was not changed
      before copying rows between partitions.
      
      fixed by setting it to TIMESTAMP_NO_AUTO_SET as the first thing
      in fast_alter_partition_table, so that all if-branches is covered.
      89b9fbd4
  17. 31 Jul, 2009 1 commit
  18. 08 Jul, 2009 1 commit
  19. 02 Jul, 2009 1 commit
    • Georgi Kodinov's avatar
      Bug #45807: crash accessing partitioned table and sql_mode · 5572f8e7
      Georgi Kodinov authored
      contains ONLY_FULL_GROUP_BY
      
      The partitioning code needs to issue a Item::fix_fields()
      on the partitioning expression in order to prepare 
      it for being evaluated.
      It does this by creating a special table and a table list 
      for the scope of the partitioning expression.
      But when checking ONLY_FULL_GROUP_BY the 
      Item_field::fix_fields() was relying that there always be
      cached_table set and was trying to use it to get the 
      select_lex of the SELECT the field's table is in.
      But the cached_table was not set by the partitioning code
      that creates the artificial TABLE_LIST used to resolve the
      partitioning expression and this resulted in a crash.
       
      Fixed by rectifying the following errors :
      1. Item_field::fix_fields() : the code that check for 
      ONLY_FULL_GROUP_BY relies on having tables with 
      cacheable_table set. This is mostly true, the only 
      two exceptions being the partitioning context table
      and the trigger context table.
      Fixed by taking the current parsing context if no pointer
      to the TABLE_LIST instance is present in the cached_table.
      
      2. fix_fields_part_func() : 
      
      2a. The code that adds the table being created to the 
      scope for the partitioning expression is mostly a copy 
      of the add_table_to_list and friends with one exception :
      it was not marking the table as cacheable (something that
      normal add_table_to_list is doing). This caused the 
      problem in the check for ONLY_FULL_GROUP_BY in 
      Item_field::fix_fields() to appear.
      Fixed by setting the correct members to make the table
      cacheable.
      The ideal structural fix for this is to use a unified 
      interface for adding a table to a table list 
      (add_table_to_list?) : noted in a TODO comment
      
      2b. The Item::fix_fields() was called with a NULL destination
      pointer. This causes uninitalized memory reads in the 
      overloaded ::fix_fields() function (namely 
      Item_field::fix_fields()) as it expects a non-zero pointer 
      there. Fixed by passing the source pointer similarly to how 
      it's done in JOIN::prepare().
      5572f8e7
  20. 19 Jun, 2009 1 commit
  21. 01 Apr, 2009 1 commit
  22. 09 Jan, 2009 1 commit
  23. 28 Dec, 2008 1 commit
    • Mattias Jonsson's avatar
      Bug#40972: some sql execution lead the whole databse crashing · 7ac77265
      Mattias Jonsson authored
      Problem was an errornous date that lead to end partition
      was before the start, leading to a crash.
      
      Solution was to check greater or equal instead of only
      equal between start and end partition.
      
      NOTE: partitioning pruning handles incorrect dates
      differently than index lookup, which can give different
      results in a partitioned table versus a non partitioned
      table for queries having 'bad' dates in the where clause.
      7ac77265
  24. 02 Dec, 2008 1 commit
    • Mattias Jonsson's avatar
      Bug#40389: REORGANIZE PARTITION crashes when only using one partition · 8f39d258
      Mattias Jonsson authored
      The non documented command 'ALTER PARTITION t REORGANIZE PARTITION'
      (without any partitions!) which only make sense for nativly
      partitioned engines, such as NDB, crashes the server if there was
      no change of number of partitions.
      
      The problem was wrong usage of fast_end_partition function,
      which led to usage of a non initialized variable.
      8f39d258
  25. 12 Nov, 2008 1 commit
  26. 10 Nov, 2008 1 commit
  27. 04 Nov, 2008 1 commit
  28. 10 Oct, 2008 1 commit
    • Mattias Jonsson's avatar
      Bug#39434: ALTER TABLE CHECK/OPTIMIZE/ANALYZE PARTITION work · f113311d
      Mattias Jonsson authored
      on non-partitioned table
      
      Problem was that partitioning specific commands was accepted
      for non partitioned tables and treated like
      ANALYZE/CHECK/OPTIMIZE/REPAIR TABLE, after bug-20129 was fixed,
      which changed the code path from mysql_alter_table to
      mysql_admin_table.
      
      Solution was to check if the table was partitioned before
      trying to execute the admin command
      f113311d
  29. 06 Oct, 2008 3 commits
    • Alexey Botchkov's avatar
      keep compiler happy · 4be617cb
      Alexey Botchkov authored
      4be617cb
    • Alexey Botchkov's avatar
    • Alexey Botchkov's avatar
      Bug#38083 Error-causing row inserted into partitioned table despite error · a206d672
      Alexey Botchkov authored
            
          problems are located in the sql_partition.cc where functions calculation
          partition_id don't expect error returned from item->val_int().
          Fixed by adding checks to these functions.
          Note  - it tries to fix more problems than just the reported bug.
            
      per-file comments:
      modified:
        mysql-test/r/partition.result
          Bug#38083 Error-causing row inserted into partitioned table despite error
              test result
        mysql-test/t/partition.test
          Bug#38083 Error-causing row inserted into partitioned table despite error
              test case
        sql/opt_range.cc
          Bug#38083 Error-causing row inserted into partitioned table despite error
              get_part_id() call fixed
        sql/partition_info.h
          Bug#38083 Error-causing row inserted into partitioned table despite error
              get_subpart_id_func interface changed. 
        sql/sql_partition.cc
          Bug#38083 Error-causing row inserted into partitioned table despite error
              various functions calculationg partition_id and subpart_id didn't expect
                  an error returned from item->val_int().  Error checks added.
      a206d672
  30. 04 Oct, 2008 1 commit
    • Mattias Jonsson's avatar
      Bug#37453: Dropping/creating index on partitioned table with · 8f64bf94
      Mattias Jonsson authored
      InnoDB Plugin locks table
      
      The fast/on-line add/drop index handler calls was not implemented
      whithin the partitioning.
      
      This implements it in the partitioning handler.
      
      Since this is only used by the not included InnoDB plugin, there
      is no test case. (Have tested it manually with the plugin, and
      it does not allow unique indexes not including partitioning
      function, or removal of pk, which in innodb generates a new pk,
      which is not in the partitioning function.)
      
      NOTE: This introduces a new handler method, and because of that
      changes the storage engine api. (One cannot use a handlerton to
      see the capabilities of a table's handler if it is partitioned.
      So I added a wrapper function in the handler that defaults to
      the handlerton function, which the partitioning handler overrides.
      8f64bf94
  31. 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
  32. 25 Feb, 2008 1 commit
    • mattiasj@witty.'s avatar
      Post push fix · 2e3ed6a2
      mattiasj@witty. authored
      Fixed a missed case in the patch for Bug#31931.
      Also makes Bug#33722 a duplicate of Bug#31931.
      Added tests for better coverage.
      Replaced some legacy function calls.
      2e3ed6a2
  33. 19 Feb, 2008 2 commits
  34. 13 Feb, 2008 1 commit
  35. 11 Feb, 2008 1 commit
  36. 28 Jan, 2008 2 commits