1. 15 Apr, 2011 3 commits
  2. 14 Apr, 2011 4 commits
    • Tor Didriksen's avatar
      Bug#11765713 58705: OPTIMIZER LET ENGINE DEPEND ON UNINITIALIZED VALUES CREATED BY OPT_SUM_QU · dd3d9477
      Tor Didriksen authored
      Valgrind warnings were caused by comparing index values to an un-initialized field.
      
      
      mysql-test/r/subselect.result:
        New test cases.
      mysql-test/t/subselect.test:
        New test cases.
      sql/opt_sum.cc:
        Add thd to opt_sum_query enabling it to test for errors.
        If we have a non-nullable index, we cannot use it to match null values,
        since set_null() will be ignored, and we might compare uninitialized data.
      sql/sql_select.cc:
        Add thd to opt_sum_query, enabling it to test for errors.
      sql/sql_select.h:
        Add thd to opt_sum_query, enabling it to test for errors.
      dd3d9477
    • Bjorn Munch's avatar
      Bug #12351213 MTR --VS-CONFIG DOES NOT WORK LIKE MTR_VS_CONFIG · e675ed06
      Bjorn Munch authored
      Fix for --vs-config applied
      Find.pm incorrectly tested an unitialized local variable instead
        of the global, corrected.
      Find.pm is also wrong in 5.5: uses a non-existent global variable. Fix when
        merging up.
      e675ed06
    • Serge Kozlov's avatar
      WL#5867, postfix for binlog_bug23533 · 7634e724
      Serge Kozlov authored
      7634e724
    • Sergey Glukhov's avatar
      Bug#11756242 48137: PROCEDURE ANALYSE() LEAKS MEMORY WHEN RETURNING NULL · 3abe56f3
      Sergey Glukhov authored
      There are two problems with ANALYSE():
      
      1. Memory leak 
         it happens because do_select() can overwrite
         JOIN::procedure field(with zero value in our case) and
         JOIN destructor don't free the memory allocated for
         JOIN::procedure. The fix is to save original JOIN::procedure
         before do_select() call and restore it after do_select
         execution.
      
      2. Wrong result
         If ANALYSE() procedure is used for the statement with LIMIT clause
         it could retrun empty result set. It happens because of missing 
         analyse::end_of_records() call. First end_send() function call
         returns NESTED_LOOP_QUERY_LIMIT and second call of end_send() with
         end_of_records flag enabled does not happen. The fix is to return
         NESTED_LOOP_OK from end_send() if procedure is active.
      
      
      mysql-test/r/analyse.result:
        test case
      mysql-test/t/analyse.test:
        test case
      sql/sql_select.cc:
        --save original JOIN::procedure before do_select() call and
          restore it after do_select execution.
        --return NESTED_LOOP_OK from end_send() if procedure is active
      3abe56f3
  3. 13 Apr, 2011 1 commit
  4. 12 Apr, 2011 3 commits
    • Sven Sandberg's avatar
      da267719
    • Sergey Glukhov's avatar
      Bug#11766270 59343: YEAR(4): INCORRECT RESULT AND VALGRIND WARNINGS WITH MIN/MAX, UNION · 7fa7a0ca
      Sergey Glukhov authored
      When we create temporary result table for UNION
      incorrect max_length for YEAR field is used and
      it leads to incorrect field value and incorrect
      result string length as YEAR field value calculation
      depends on field length.
      The fix is to use underlying item max_length for
      Item_sum_hybrid::max_length intialization.
      
      
      mysql-test/r/func_group.result:
        test case
      mysql-test/t/func_group.test:
        test case
      sql/field.cc:
        added assert
      sql/item_sum.cc:
        init Item_sum_hybrid::max_length with 
        use underlying item max_length for
        INT result type.
      7fa7a0ca
    • Sergey Glukhov's avatar
      Bug#11766212 59270: NOT IN (YEAR( ... ), ... ) PRODUCES MANY VALGRIND WARNINGS · 33c2a5e7
      Sergey Glukhov authored
      Valgrind warning happens due to early null values check
      in Item_func_in::fix_length_and_dec(before item evaluation).
      As result null value items with uninitialized values are
      placed into array and it leads to valgrind warnings during
      value array sorting.
      The fix is to check null value after item evaluation, item
      is evaluated in in_array::set() method.
      
      
      mysql-test/r/func_in.result:
        test case
      mysql-test/t/func_in.test:
        test case
      sql/item_cmpfunc.cc:
        The fix is to check null value after item evaluation.
      33c2a5e7
  5. 11 Apr, 2011 5 commits
  6. 08 Apr, 2011 2 commits
    • Gleb Shchepa's avatar
      Bug #11829681 - 60295: ERROR 1356 ON VIEW THAT EXECUTES FINE AS A QUERY · a77bc598
      Gleb Shchepa authored
      Select from a view with the underlying HAVING clause failed with a
      message: "1356: View '...' references invalid table(s) or column(s)
      or function(s) or definer/invoker of view lack rights to use them"
      
      The bug is a regression of the fix for bug 11750328 - 40825 (similar
      case, but the HAVING cause references an aliased field).
      In the old fix for bug 40825 the Item_field::name_length value has
      been used in place of the real length of Item_field::name. However,
      in some cases Item_field::name_length is not in sync with the
      actual name length (TODO: combine name and name_length into a
      solid String field).
      
      The Item_ref::print() method has been modified to calculate actual
      name length every time.
      
      
      mysql-test/r/view.result:
        Test case for bug #11829681
      mysql-test/t/view.test:
        Test case for bug #11829681
      sql/item.cc:
        Bug #11829681 - 60295: ERROR 1356 ON VIEW THAT EXECUTES FINE AS A QUERY
        
        The Item_ref::print() method has been modified to calculate actual
        name length every time.
      sql/item.h:
        Minor commentary.
      a77bc598
    • Nirbhay Choubey's avatar
      Bug#11765157 - 58090: mysqlslap drops schema specified in · cb0e49c0
      Nirbhay Choubey authored
                     create_schema if auto-generate-sql also set.
      
      mysqlslap uses a schema to run its tests on and later
      drops it if auto-generate-sql is used. This can be a
      problem, if the schema is an already existing one.
      
      If create-schema is used with auto-generate-sql option,
      mysqlslap while performing the cleanup, drops the specified
      database.
      
      Fixed by introducing an option --no-drop, which, if used,
      will prevent the dropping of schema at the end of the test.
      
      
      client/client_priv.h:
        Bug#11765157 - 58090: mysqlslap drops schema specified in
                       create_schema if auto-generate-sql also set.
        
        Added an option.
      client/mysqlslap.c:
        Bug#11765157 - 58090: mysqlslap drops schema specified in
                       create_schema if auto-generate-sql also set.
        
        Introduced an option 'no-drop' to forbid the removal of schema
        even if 'create' or 'auto-generate-sql' options are used.
      mysql-test/r/mysqlslap.result:
        Added a testcase for Bug#11765157.
      mysql-test/t/mysqlslap.test:
        Added a testcase for Bug#11765157.
      cb0e49c0
  7. 07 Apr, 2011 1 commit
  8. 05 Apr, 2011 1 commit
  9. 04 Apr, 2011 2 commits
    • Georgi Kodinov's avatar
      Bug #11758687: 50924: object names not resolved correctly · 5321b3a5
      Georgi Kodinov authored
         on lctn2 systems
      
      There was a local variable in get_all_tables() to store the 
      "original" value of the database name as it can get lowercased
      depending on the lower_case_table_name value.
      get_all_tables() iterates over database names and for each 
      database iterates over the tables in it.
      The "original" db name was assigned in the table names loop.
      Thus the first table is ok, but the second and subsequent tables
      get the lowercased name from processing the first table.
      Fixed by moving the assignment of the original database name
      from the inner (table name) to the outer (database name) loop.
      Test suite added.
      5321b3a5
    • Vasil Dimov's avatar
      Merge mysql-5.1-innodb -> mysql-5.1 · d2d7aa48
      Vasil Dimov authored
      d2d7aa48
  10. 31 Mar, 2011 4 commits
  11. 30 Mar, 2011 5 commits
    • Magne Mahre's avatar
      Fix-up after commit of Bug#11900714 · b8faa8f2
      Magne Mahre authored
      The patch fixes a build problem on MacOSX, where
      the compiler complains about unused parameters.
      b8faa8f2
    • Bjorn Munch's avatar
    • Marko Mäkelä's avatar
      Bug#11877216 InnoDB too eager to commit suicide on a busy server · ddec6ecd
      Marko Mäkelä authored
      sync_array_print_long_waits(): Return the longest waiting thread ID
      and the longest waited-for lock. Only if those remain unchanged
      between calls in srv_error_monitor_thread(), increment
      fatal_cnt. Otherwise, reset fatal_cnt.
      
      Background: There is a built-in watchdog in InnoDB whose purpose is to
      kill the server when some thread is stuck waiting for a mutex or
      rw-lock. Before this fix, the logic was flawed.
      
      The function sync_array_print_long_waits() returns TRUE if it finds a
      lock wait that exceeds 10 minutes (srv_fatal_semaphore_wait_threshold).
      The function srv_error_monitor_thread() will kill the server if this
      happens 10 times in a row (fatal_cnt reaches 10), checked every 30
      seconds. This is wrong, because this situation does not mean that the
      server is hung. If the server is very busy for a little over 15
      minutes, it will be killed.
      
      Consider this example. Thread T1 is waiting for mutex M. Some time
      later, threads T2..Tn start waiting for the same mutex M. If T1 keeps
      waiting for 600 seconds, fatal_cnt will be incremented to 1. So far,
      so good. Now, if M is granted to T1, the server was obviously not
      stuck. But, T2..Tn keeps waiting, and their wait time will be longer
      than 600 seconds. If 5 minutes later, some Tn has still been waiting
      for more than 10 minutes for the mutex M, the server can be killed,
      even though it is not stuck.
      
      rb:622 approved by Jimmy Yang
      ddec6ecd
    • Sergey Glukhov's avatar
      Bug#11766124 59164: VALGRIND: UNINITIALIZED VALUE IN NUMBER_TO_DATETIME · a7d383cb
      Sergey Glukhov authored
      Valgrind warning happens due to missing NULL value check in
      Item::get_date. The fix is to add this check.
      
      
      mysql-test/r/func_time.result:
        test case
      mysql-test/t/func_time.test:
        test case
      sql/item.cc:
        added check for NULL value
      a7d383cb
    • Sergey Glukhov's avatar
      Bug#11766126 59166: ANOTHER DATETIME VALGRIND UNINITIALIZED WARNING · 3b7f0445
      Sergey Glukhov authored
      Valgrind warning happens because null values check happens too late
      in Item_func_month::val_str(after result string calculation).The fix
      is to check null value before result string calculation.
      
      
      mysql-test/r/func_time.result:
        test case
      mysql-test/t/func_time.test:
        test case
      sql/item_timefunc.h:
        check null value before result string calculation.
      3b7f0445
  12. 29 Mar, 2011 1 commit
    • Jon Olav Hauglid's avatar
      Bug# 11763784 (former 56541) · 4e26a41f
      Jon Olav Hauglid authored
      ASSERTION TABLE->DB_STAT FAILED IN
      SQL_BASE.CC::OPEN_TABLE() DURING I_S Q
      
      This assert could be triggered if a statement requiring a name
      lock on a table (e.g. DROP TRIGGER) executed concurrently
      with an I_S query which also used the table.
      
      One connection first started an I_S query that opened a given table.
      Then another connection started a statement requiring a name lock
      on the same table. This statement was blocked since the table was
      in use by the I_S query. When the I_S query resumed and tried to
      open the table again as part of get_all_tables(), it would encounter
      a table instance with an old version number representing the pending
      name lock. Since I_S queries ignore version checks and thus pending
      name locks, it would try to continue. This caused it to encounter
      the assert. The assert checked that the TABLE instance found with a
      different version, was a real, open table. However, since this TABLE
      instance instead represented a pending name lock, the check would
      fail and trigger the assert.
      
      This patch fixes the problem by removing the assert. It is ok for
      TABLE::db_stat to be 0 in this case since the TABLE instance can
      represent a pending name lock.
      
      Test case added to lock_sync.test.
      4e26a41f
  13. 28 Mar, 2011 8 commits