An error occurred fetching the project authors.
  1. 05 Oct, 2009 1 commit
  2. 29 Sep, 2009 1 commit
    • Alfranio Correia's avatar
      WL#4828 and BUG#45747 · 5280dc82
      Alfranio Correia authored
      NOTE: Backporting the patch to next-mr.
      
      WL#4828 Augment DBUG_ENTER/DBUG_EXIT to crash MySQL in different functions
      -------
      
      The assessment of the replication code in the presence of faults is extremely
      import to increase reliability. In particular, one needs to know if servers
      will either correctly recovery or print out appropriate error messages thus
      avoiding unexpected problems in a production environment.
      
      In order to accomplish this, the current patch refactories the debug macros
      already provided in the source code and introduces three new macros that
      allows to inject faults, specifically crashes, while entering or exiting a
      function or method. For instance, to crash a server while returning from
      the init_slave function (see module sql/slave.cc), one needs to do what
      follows:
      
      1 - Modify the source replacing DBUG_RETURN by DBUG_CRASH_RETURN;
      
        DBUG_CRASH_RETURN(0);
      
      2 - Use the debug variable to activate dbug instructions:
      
        SET SESSION debug="+d,init_slave_crash_return";
      
      The new macros are briefly described below:
      
      DBUG_CRASH_ENTER (function) is equivalent to DBUG_ENTER which registers the
      beginning of a function but in addition to it allows for crashing the server
      while entering the function if the appropriate dbug instruction is activate.
      In this case, the dbug instruction should be "+d,function_crash_enter".
      
      DBUG_CRASH_RETURN (value) is equivalent to DBUG_RETURN which notifies the
      end of a function but in addition to it allows for crashing the server
      while returning from the function if the appropriate dbug instruction is
      activate. In this case, the dbug instruction should be
      "+d,function_crash_return". Note that "function" should be the same string
      used by either the DBUG_ENTER or DBUG_CRASH_ENTER.
      
      DBUG_CRASH_VOID_RETURN (value) is equivalent to DBUG_VOID_RETURN which
      notifies the end of a function but in addition to it allows for crashing
      the server while returning from the function if the appropriate dbug
      instruction is activate. In this case, the dbug instruction should be
      "+d,function_crash_return". Note that "function" should be the same string
      used by either the DBUG_ENTER or DBUG_CRASH_ENTER.
      
      To inject other faults, for instance, wrong return values, one should rely
      on the macros already available. The current patch also removes a set of
      macros that were either not being used or were redundant as other macros
      could be used to provide the same feature. In the future, we also consider
      dynamic instrumentation of the code.
      
      
      BUG#45747 DBUG_CRASH_* is not setting the strict option
      ---------
            
      When combining DBUG_CRASH_* with "--debug=d:t:i:A,file" the server crashes
      due to a call to the abort function in the DBUG_CRASH_* macro althought the
      appropriate keyword has not been set.
      5280dc82
  3. 23 Sep, 2009 1 commit
  4. 10 Sep, 2009 2 commits
  5. 02 Sep, 2009 1 commit
  6. 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
  7. 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
  8. 31 Jul, 2009 1 commit
  9. 08 Jul, 2009 1 commit
  10. 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
  11. 19 Jun, 2009 1 commit
  12. 01 Apr, 2009 1 commit
  13. 09 Jan, 2009 1 commit
  14. 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
  15. 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
  16. 12 Nov, 2008 1 commit
  17. 10 Nov, 2008 1 commit
  18. 04 Nov, 2008 1 commit
  19. 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
  20. 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
  21. 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
  22. 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
  23. 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
  24. 19 Feb, 2008 2 commits
  25. 13 Feb, 2008 1 commit
  26. 11 Feb, 2008 1 commit
  27. 28 Jan, 2008 2 commits
  28. 09 Jan, 2008 1 commit
    • mattiasj@client-10-129-10-137.upp.off.mysql.com's avatar
      Bug#31931 Partitions: unjustified 'mix of handlers' error message · a6a97748
      Problem was that the mix of handlers was not consistent between
      CREATE and ALTER
      
      changed so that it works like:
          - All partitions must use the same engine
            AND it must be the same as the table.
          - if one does NOT specify an engine on the table level
            then one must either NOT specify any engine on any
            partition/subpartition OR for ALL partitions/subpartitions
      
      Note: that after a table have been created, the storage engine
      is specified for all parts of the table (table/partition/subpartition)
      and so when using alter, one does not need to specify it (unless one
      wants to change the storage engine, then one have to specify it on the
      table level)
      a6a97748
  29. 20 Dec, 2007 1 commit
    • kostja@bodhi.(none)'s avatar
      A pre-requisite for the fix for Bug#12713 "Error in a stored function · dfe685e6
      kostja@bodhi.(none) authored
      called from a SELECT doesn't cause ROLLBACK of state"
      Make private all class handler methods (PSEA API) that may modify
      data. Introduce and deploy public ha_* wrappers for these methods in 
      all sql/.
      This necessary to keep track of all data modifications in sql/,
      which is in turn necessary to be able to optimize two-phase
      commit of those transactions that do not modify data.
      dfe685e6
  30. 12 Dec, 2007 1 commit
    • kostja@bodhi.(none)'s avatar
      Bug#12713 "Error in a stored function called from a SELECT doesn't · ebb9c5d9
      kostja@bodhi.(none) authored
      cause ROLLBACK of statement", part 1. Review fixes.
      
      Do not send OK/EOF packets to the client until we reached the end of 
      the current statement.
      This is a consolidation, to keep the functionality that is shared by all 
      SQL statements in one place in the server.
      Currently this functionality includes:
      - close_thread_tables()
      - log_slow_statement().
      
      After this patch and the subsequent patch for Bug#12713, it shall also include:
      - ha_autocommit_or_rollback()
      - net_end_statement()
      - query_cache_end_of_result().
      
      In future it may also include:
      - mysql_reset_thd_for_next_command().
      ebb9c5d9
  31. 26 Nov, 2007 1 commit
    • ramil/ram@mysql.com/ramil.myoffice.izhnet.ru's avatar
      Fix for bug #29258: Partitions: search fails for maximum unsigned bigint · beff6193
      Problems: 
        1. looking for a matching partition we miss the fact that the maximum 
           allowed value is in the PARTITION p LESS THAN MAXVALUE.
        2. one can insert maximum value if numeric maximum value is the last range.
           (should only work if LESS THAN MAXVALUE).
        3. one cannot have both numeric maximum value and MAXVALUE string as ranges 
          (the same value, but different meanings).
      
      Fix: consider the maximum value as a supremum.
      beff6193
  32. 23 Nov, 2007 1 commit
  33. 20 Nov, 2007 1 commit
  34. 15 Nov, 2007 1 commit
    • istruewing@stella.local's avatar
      Bug#26379 - Combination of FLUSH TABLE and REPAIR TABLE · 06052741
      istruewing@stella.local authored
                  corrupts a MERGE table
      Bug 26867 - LOCK TABLES + REPAIR + merge table result in
                  memory/cpu hogging
      Bug 26377 - Deadlock with MERGE and FLUSH TABLE
      Bug 25038 - Waiting TRUNCATE
      Bug 25700 - merge base tables get corrupted by
                  optimize/analyze/repair table
      Bug 30275 - Merge tables: flush tables or unlock tables
                  causes server to crash
      Bug 19627 - temporary merge table locking
      Bug 27660 - Falcon: merge table possible
      Bug 30273 - merge tables: Can't lock file (errno: 155)
      
      The problems were:
      
      Bug 26379 - Combination of FLUSH TABLE and REPAIR TABLE
                      corrupts a MERGE table
      
        1. A thread trying to lock a MERGE table performs busy waiting while
           REPAIR TABLE or a similar table administration task is ongoing on
           one or more of its MyISAM tables.
        
        2. A thread trying to lock a MERGE table performs busy waiting until all
           threads that did REPAIR TABLE or similar table administration tasks
           on one or more of its MyISAM tables in LOCK TABLES segments do UNLOCK
           TABLES. The difference against problem #1 is that the busy waiting
           takes place *after* the administration task. It is terminated by
           UNLOCK TABLES only.
        
        3. Two FLUSH TABLES within a LOCK TABLES segment can invalidate the
           lock. This does *not* require a MERGE table. The first FLUSH TABLES
           can be replaced by any statement that requires other threads to
           reopen the table. In 5.0 and 5.1 a single FLUSH TABLES can provoke
           the problem.
      
      Bug 26867 - LOCK TABLES + REPAIR + merge table result in
                  memory/cpu hogging
      
        Trying DML on a MERGE table, which has a child locked and
        repaired by another thread, made an infinite loop in the server.
      
      Bug 26377 - Deadlock with MERGE and FLUSH TABLE
      
        Locking a MERGE table and its children in parent-child order
        and flushing the child deadlocked the server.
      
      Bug 25038 - Waiting TRUNCATE
      
        Truncating a MERGE child, while the MERGE table was in use,
        let the truncate fail instead of waiting for the table to
        become free.
      
      Bug 25700 - merge base tables get corrupted by
                  optimize/analyze/repair table
      
        Repairing a child of an open MERGE table corrupted the child.
        It was necessary to FLUSH the child first.
      
      Bug 30275 - Merge tables: flush tables or unlock tables
                  causes server to crash
      
        Flushing and optimizing locked MERGE children crashed the server.
      
      Bug 19627 - temporary merge table locking
      
        Use of a temporary MERGE table with non-temporary children
        could corrupt the children.
      
        Temporary tables are never locked. So we do now prohibit
        non-temporary chidlren of a temporary MERGE table.
      
      Bug 27660 - Falcon: merge table possible
      
        It was possible to create a MERGE table with non-MyISAM children.
      
      Bug 30273 - merge tables: Can't lock file (errno: 155)
      
        This was a Windows-only bug. Table administration statements
        sometimes failed with "Can't lock file (errno: 155)".
      
      These bugs are fixed by a new implementation of MERGE table open.
      
      When opening a MERGE table in open_tables() we do now add the
      child tables to the list of tables to be opened by open_tables()
      (the "query_list"). The children are not opened in the handler at
      this stage.
      
      After opening the parent, open_tables() opens each child from the
      now extended query_list. When the last child is opened, we remove
      the children from the query_list again and attach the children to
      the parent. This behaves similar to the old open. However it does
      not open the MyISAM tables directly, but grabs them from the already
      open children.
      
      When closing a MERGE table in close_thread_table() we detach the
      children only. Closing of the children is done implicitly because
      they are in thd->open_tables.
      
      For more detail see the comment at the top of ha_myisammrg.cc.
      
      Changed from open_ltable() to open_and_lock_tables() in all places
      that can be relevant for MERGE tables. The latter can handle tables
      added to the list on the fly. When open_ltable() was used in a loop
      over a list of tables, the list must be temporarily terminated
      after every table for open_and_lock_tables().
      table_list->required_type is set to FRMTYPE_TABLE to avoid open of
      special tables. Handling of derived tables is suppressed.
      These details are handled by the new function
      open_n_lock_single_table(), which has nearly the same signature as
      open_ltable() and can replace it in most cases.
      
      In reopen_tables() some of the tables open by a thread can be
      closed and reopened. When a MERGE child is affected, the parent
      must be closed and reopened too. Closing of the parent is forced
      before the first child is closed. Reopen happens in the order of
      thd->open_tables. MERGE parents do not attach their children
      automatically at open. This is done after all tables are reopened.
      So all children are open when attaching them.
      
      Special lock handling like mysql_lock_abort() or mysql_lock_remove()
      needs to be suppressed for MERGE children or forwarded to the parent.
      This depends on the situation. In loops over all open tables one
      suppresses child lock handling. When a single table is touched,
      forwarding is done.
      
      Behavioral changes:
      ===================
      
      This patch changes the behavior of temporary MERGE tables.
      Temporary MERGE must have temporary children.
      The old behavior was wrong. A temporary table is not locked. Hence
      even non-temporary children were not locked. See
      Bug 19627 - temporary merge table locking.
      
      You cannot change the union list of a non-temporary MERGE table
      when LOCK TABLES is in effect. The following does *not* work:
      CREATE TABLE m1 ... ENGINE=MRG_MYISAM ...;
      LOCK TABLES t1 WRITE, t2 WRITE, m1 WRITE;
      ALTER TABLE m1 ... UNION=(t1,t2) ...;
      However, you can do this with a temporary MERGE table.
      
      You cannot create a MERGE table with CREATE ... SELECT, neither
      as a temporary MERGE table, nor as a non-temporary MERGE table.
      CREATE TABLE m1 ... ENGINE=MRG_MYISAM ... SELECT ...;
      Gives error message: table is not BASE TABLE.
      06052741
  35. 11 Nov, 2007 1 commit