1. 05 Jan, 2011 2 commits
  2. 04 Jan, 2011 1 commit
    • Jon Olav Hauglid's avatar
      Bug #50619 assert in handler::update_auto_increment · 78df8c4f
      Jon Olav Hauglid authored
      This assert could be triggered if -1 was inserted into
      an auto increment column by a statement writing more than
      one row.
      
      Unless explicitly given, an interval of auto increment values
      is generated when a statement first needs an auto increment
      value. The triggered assert checks that the auto increment
      counter is equal to or higher than the lower bound of this
      interval.
      
      Generally, the auto increment counter starts at 1 and is
      incremented by 1 each time it is used. However, inserting an
      explicit value into the auto increment column, sets the auto
      increment counter to this value + 1 if this value is higher
      than the current value of the auto increment counter.
      
      This bug was triggered if the explicit value was -1. Since the
      value was converted to unsigned before any comparisons were made,
      it was found to be higher than the current vale of the auto
      increment counter and the counter was set to -1 + 1. This value
      was below the reserved interval and caused the assert to be
      triggered the next time the statement tried to write a row.
      
      With the patch for Bug#39828, this bug is no longer repeatable.
      Now, -1 + 1 is detected as an "overflow" which causes the auto
      increment counter to be set to ULONGLONG_MAX. This avoids hitting
      the assert for the next insert and causes a new interval of
      auto increment values to be generated. This resolves the issue.
      
      This patch therefore only contains a regression test and no code
      changes. Test case added to auto_increment.test.
      78df8c4f
  3. 31 Dec, 2010 1 commit
  4. 29 Dec, 2010 4 commits
  5. 28 Dec, 2010 2 commits
    • Kent Boortz's avatar
      Merge · 920d185f
      Kent Boortz authored
      920d185f
    • Kent Boortz's avatar
      - Added/updated copyright headers · fddb1f1b
      Kent Boortz authored
      - Removed files specific to compiling on OS/2
      - Removed files specific to SCO Unix packaging
      - Removed "libmysqld/copyright", text is included in documentation
      - Removed LaTeX headers for NDB Doxygen documentation
      - Removed obsolete NDB files
      - Removed "mkisofs" binaries
      - Removed the "cvs2cl.pl" script
      - Changed a few GPL texts to use "program" instead of "library"
      fddb1f1b
  6. 24 Dec, 2010 1 commit
    • Sergey Glukhov's avatar
      Bug#57810 case/when/then : Assertion failed: length || !scale · b69b46c7
      Sergey Glukhov authored
      ASSERT happens due to improper calculation of the max_length
      in Item_func_div object, if dividend has max_length == 0 then
      Item_func_div::max_length is set to 0 under some circumstances.
      The fix:
      If decimals == NOT_FIXED_DEC then set
      Item_func_div::max_length to max possible
      DOUBLE length value.
      b69b46c7
  7. 21 Dec, 2010 5 commits
    • Sergey Glukhov's avatar
      automerge · 8b0f0a97
      Sergey Glukhov authored
      8b0f0a97
    • Sergey Glukhov's avatar
      test case fix · 42bed4be
      Sergey Glukhov authored
      42bed4be
    • Sven Sandberg's avatar
      BUG#59084: rpl_do_grant started to fail on FreeBSD (presumably after BUG#49978) · 0d87c6ed
      Sven Sandberg authored
      Problem: master executed a statement that would fail on slave
      (namely, DROP USER 'create_rout_db'@'localhost').
      Then the test did:
        --let $rpl_only_running_threads= 1
        --source include/rpl_reset.inc
      rpl_reset.inc calls rpl_sync.inc, which first checks which of
      the threads are running and then syncs those threads that are
      running. If the SQL thread fails after the check, the sync will
      fail. So there was a race in the test and it failed on some
      slow hosts.
      Fix: Don't replicate the failing statement.
      0d87c6ed
    • Sergey Glukhov's avatar
      Bug#58030 crash in Item_func_geometry_from_text::val_str · c4b29069
      Sergey Glukhov authored
      Item_sum_max/Item_sum_min incorrectly set null_value flag and
      attempt to get result in parent functions leads to crash.
      This happens due to double evaluation of the function argumet.
      First evaluation happens in the comparator and second one
      happens in Item_cache::cache_value().
      The fix is to introduce new Item_cache object which
      holds result of the argument and use this cached value
      as an argument of the comparator.
      c4b29069
    • 's avatar
      Bug #56662 Assertion failed: next_insert_id == 0, file .\handler.cc · 16ca2deb
      authored
      Normally, auto_increment value is generated for the column by
      inserting either NULL or 0 into it. NO_AUTO_VALUE_ON_ZERO
      suppresses this behavior for 0 so that only NULL generates
      the auto_increment value. This behavior is also followed by
      a slave, specifically by the SQL Thread, when applying events
      in the statement format from a master. However, when applying
      events in the row format, the flag was ignored thus causing
      an assertion failure:
      "Assertion failed: next_insert_id == 0, file .\handler.cc"
      
      In fact, we never need to generate a auto_increment value for
      the column when applying events in row format on slave. So we
      don't allow it to happen by using 'MODE_NO_AUTO_VALUE_ON_ZERO'.
      
      Refactoring: Get rid of all the sql_mode checks to rows_log_event
      when applying it for avoiding problems caused by the inconsistency
      of the sql_mode on slave and master as the sql_mode is not set for
      Rows_log_event.
      16ca2deb
  8. 20 Dec, 2010 1 commit
    • Sven Sandberg's avatar
      Fixed pb failure. · c676f125
      Sven Sandberg authored
      Problem: Warnings for truncated data were generated on hosts with
      long host names because @@hostname was inserted into a CHAR(40) column.
      Fix: Change CHAR(40) to TEXT.
      c676f125
  9. 19 Dec, 2010 1 commit
    • Sven Sandberg's avatar
      BUG#49978: Replication tests don't clean up replication state at the end · 09c80e12
      Sven Sandberg authored
      Major replication test framework cleanup. This does the following:
       - Ensure that all tests clean up the replication state when they
         finish, by making check-testcase check the output of SHOW SLAVE STATUS.
         This implies:
          - Slave must not be running after test finished. This is good
            because it removes the risk for sporadic errors in subsequent
            tests when a test forgets to sync correctly.
          - Slave SQL and IO errors must be cleared when test ends. This is
            good because we will notice if a test gets an unexpected error in
            the slave threads near the end.
          - We no longer have to clean up before a test starts.
       - Ensure that all tests that wait for an error in one of the slave
         threads waits for a specific error. It is no longer possible to
         source wait_for_slave_[sql|io]_to_stop.inc when there is an error
         in one of the slave threads. This is good because:
          - If a test expects an error but there is a bug that causes
            another error to happen, or if it stops the slave thread without
            an error, then we will notice.
          - When developing tests, wait_for_*_to_[start|stop].inc will fail
            immediately if there is an error in the relevant slave thread.
            Before this patch, we had to wait for the timeout.
       - Remove duplicated and repeated code for setting up unusual replication
         topologies. Now, there is a single file that is capable of setting
         up arbitrary topologies (include/rpl_init.inc, but
         include/master-slave.inc is still available for the most common
         topology). Tests can now end with include/rpl_end.inc, which will clean
         up correctly no matter what topology is used. The topology can be
         changed with include/rpl_change_topology.inc.
       - Improved debug information when tests fail. This includes:
          - debug info is printed on all servers configured by include/rpl_init.inc
          - User can set $rpl_debug=1, which makes auxiliary replication files
            print relevant debug info.
       - Improved documentation for all auxiliary replication files. Now they
         describe purpose, usage, parameters, and side effects.
       - Many small code cleanups:
          - Made have_innodb.inc output a sensible error message.
          - Moved contents of rpl000017-slave.sh into rpl000017.test
          - Added mysqltest variables that expose the current state of
            disable_warnings/enable_warnings and friends.
          - Too many to list here: see per-file comments for details.
      09c80e12
  10. 17 Dec, 2010 5 commits
  11. 16 Dec, 2010 2 commits
  12. 15 Dec, 2010 1 commit
  13. 14 Dec, 2010 10 commits
    • Gleb Shchepa's avatar
    • Gleb Shchepa's avatar
      backport of bug #54476 fix from 5.1-bugteam to 5.0-bugteam. · 01521a0a
      Gleb Shchepa authored
      Original revid: alexey.kopytov@sun.com-20100723115254-jjwmhq97b9wl932l
      
       > Bug #54476: crash when group_concat and 'with rollup' in
       >                      prepared statements
       >
       > Using GROUP_CONCAT() together with the WITH ROLLUP modifier
       > could crash the server.
       >
       > The reason was a combination of several facts:
       >
       > 1. The Item_func_group_concat class stores pointers to ORDER
       > objects representing the columns in the ORDER BY clause of
       > GROUP_CONCAT().
       >
       > 2. find_order_in_list() called from
       > Item_func_group_concat::setup() modifies the ORDER objects so
       > that their 'item' member points to the arguments list
       > allocated in the Item_func_group_concat constructor.
       >
       > 3. In some cases (e.g. in JOIN::rollup_make_fields) a copy of
       > the original Item_func_group_concat object could be created by
       > using the Item_func_group_concat::Item_func_group_concat(THD
       > *thd, Item_func_group_concat *item) copy constructor. The
       > latter essentially creates a shallow copy of the source
       > object. Memory for the arguments array is allocated on
       > thd->mem_root, but the pointers for arguments and ORDER are
       > copied verbatim.
       >
       > What happens in the test case is that when executing the query
       > for the first time, after a copy of the original
       > Item_func_group_concat object has been created by
       > JOIN::rollup_make_fields(), find_order_in_list() is called for
       > this new object. It then resolves ORDER BY by modifying the
       > ORDER objects so that they point to elements of the arguments
       > array which is local to the cloned object. When thd->mem_root
       > is freed upon completing the execution, pointers in the ORDER
       > objects become invalid. Those ORDER objects, however, are also
       > shared with the original Item_func_group_concat object which is
       > preserved between executions of a prepared statement. So the
       > first call to find_order_in_list() for the original object on
       > the second execution tries to dereference an invalid pointer.
       >
       > The solution is to create copies of the ORDER objects when
       > copying Item_func_group_concat to not leave any stale pointers
       > in other instances with different lifecycles.
      01521a0a
    • Luis Soares's avatar
      BUG#46697 · e4ad12dc
      Luis Soares authored
      Autmoerging into latest mysql-5.1-bugteam.
      e4ad12dc
    • Luis Soares's avatar
      BUG 46697 · 1d0eae6f
      Luis Soares authored
      Addressing review comments.
      1d0eae6f
    • Luis Soares's avatar
      089327bf
    • Sergey Glukhov's avatar
      Bug#57818 string conversion function died · 622ae418
      Sergey Glukhov authored
      Bug#57913 large negative number to string conversion functions crash
      String object which is used as result container of the item
      has uninitialized 'str_charset' field. This object
      might be used later to preform some internal operations
      and str_charset field is involved in these operations.
      It leads to crash.
      The fix is to intialize str_charset in my_decimal2string() func.
      622ae418
    • Mattias Jonsson's avatar
      merge · 6e3314b0
      Mattias Jonsson authored
      6e3314b0
    • Mattias Jonsson's avatar
      merge · c070dc57
      Mattias Jonsson authored
      c070dc57
    • Mattias Jonsson's avatar
      Bug#45717: A few test cases are disabled due to closed Bug#30577 · cd27e25d
      Mattias Jonsson authored
      Backport from 5.5. OK from Anitha G. to push to 5.1.
      
      Removed floor(float_col) tests, enabled floor(decimal_col) tests
      cd27e25d
    • Sergey Glukhov's avatar
      Fixed following problems: · cd36a6a5
      Sergey Glukhov authored
      --Bug#52157 various crashes and assertions with multi-table update, stored function
      --Bug#54475 improper error handling causes cascading crashing failures in innodb/ndb
      --Bug#57703 create view cause Assertion failed: 0, file .\item_subselect.cc, line 846
      --Bug#57352 valgrind warnings when creating view
      --Recently discovered problem when a nested materialized derived table is used
        before being populated and it leads to incorrect result
      
      We have several modes when we should disable subquery evaluation.
      The reasons for disabling are different. It could be
      uselessness of the evaluation as in case of 'CREATE VIEW'
      or 'PREPARE stmt', or we should disable subquery evaluation
      if tables are not locked yet as it happens in bug#54475, or
      too early evaluation of subqueries can lead to wrong result
      as it happened in Bug#19077.
      Main problem is that if subquery items are treated as const
      they are evaluated in ::fix_fields(), ::fix_length_and_dec()
      of the parental items as a lot of these methods have
      Item::val_...() calls inside.
      We have to make subqueries non-const to prevent unnecessary
      subquery evaluation. At the moment we have different methods
      for this. Here is a list of these modes:
      
      1. PREPARE stmt;
      We use UNCACHEABLE_PREPARE flag.
      It is set during parsing in sql_parse.cc, mysql_new_select() for
      each SELECT_LEX object and cleared at the end of PREPARE in
      sql_prepare.cc, init_stmt_after_parse(). If this flag is set
      subquery becomes non-const and evaluation does not happen.
      
      2. CREATE|ALTER VIEW, SHOW CREATE VIEW, I_S tables which
         process FRM files
      We use LEX::view_prepare_mode field. We set it before
      view preparation and check this flag in
      ::fix_fields(), ::fix_length_and_dec().
      Some bugs are fixed using this approach,
      some are not(Bug#57352, Bug#57703). The problem here is
      that we have a lot of ::fix_fields(), ::fix_length_and_dec()
      where we use Item::val_...() calls for const items.
      
      3. Derived tables with subquery = wrong result(Bug19077)
      The reason of this bug is too early subquery evaluation.
      It was fixed by adding Item::with_subselect field
      The check of this field in appropriate places prevents
      const item evaluation if the item have subquery.
      The fix for Bug19077 fixes only the problem with
      convert_constant_item() function and does not cover
      other places(::fix_fields(), ::fix_length_and_dec() again)
      where subqueries could be evaluated.
      
      Example:
      CREATE TABLE t1 (i INT, j BIGINT);
      INSERT INTO t1 VALUES (1, 2), (2, 2), (3, 2);
      SELECT * FROM (SELECT MIN(i) FROM t1
      WHERE j = SUBSTRING('12', (SELECT * FROM (SELECT MIN(j) FROM t1) t2))) t3;
      DROP TABLE t1;
      
      4. Derived tables with subquery where subquery
         is evaluated before table locking(Bug#54475, Bug#52157)
      
      Suggested solution is following:
      
      -Introduce new field LEX::context_analysis_only with the following
       possible flags:
       #define CONTEXT_ANALYSIS_ONLY_PREPARE 1
       #define CONTEXT_ANALYSIS_ONLY_VIEW    2
       #define CONTEXT_ANALYSIS_ONLY_DERIVED 4
      -Set/clean these flags when we perform
       context analysis operation
      -Item_subselect::const_item() returns
       result depending on LEX::context_analysis_only.
       If context_analysis_only is set then we return
       FALSE that means that subquery is non-const.
       As all subquery types are wrapped by Item_subselect
       it allow as to make subquery non-const when
       it's necessary.
      cd36a6a5
  14. 13 Dec, 2010 3 commits
  15. 09 Dec, 2010 1 commit