1. 30 Sep, 2008 1 commit
  2. 29 Sep, 2008 1 commit
    • Alexey Botchkov's avatar
      Bug#37949 Crash if argument to SP is a subquery that returns more than one row · b6f4b1c0
      Alexey Botchkov authored
           JOIN for the subselect wasn't cleaned if we came upon an error
           during sub_select() execution. That leads to the assertion failure
           in close_thread_tables()
      
           part of the 6.0 code backported
      
      per-file comments:
        mysql-test/r/sp-error.result
      Bug#37949 Crash if argument to SP is a subquery that returns more than one row 
          test result
      
        mysql-test/t/sp-error.test
      Bug#37949 Crash if argument to SP is a subquery that returns more than one row 
          test case
      
        sql/sp_head.cc
      Bug#37949 Crash if argument to SP is a subquery that returns more than one row 
          lex->unit.cleanup() call added if not substatement
      b6f4b1c0
  3. 23 Sep, 2008 1 commit
  4. 20 Sep, 2008 4 commits
  5. 18 Sep, 2008 2 commits
  6. 17 Sep, 2008 2 commits
  7. 16 Sep, 2008 2 commits
    • Matthias Leich's avatar
      Fix for Bug#38184 : main.federated fails sporadically · 2130b894
      Matthias Leich authored
      Details:
      - backport of some improvements which prevent sporadic
        failures from 5.1 to 5.0
      - @@GLOBAL.CONCURRENT_INSERT= 0 also for slave server
      - --sorted_result before all selects which have result
        sets with more than one row
      - Replace error numbers by error names
      2130b894
    • Vladislav Vaintroub's avatar
      Bug#35987 - post-review fix · fd70d5e9
      Vladislav Vaintroub authored
      Correct usage of strncat() in get_symbol_path()
      
      3rd parameter to strncat is changed to be count of 
      remaining bytes in the output buffer minus 1.
      
      fd70d5e9
  8. 15 Sep, 2008 2 commits
    • Patrick Crews's avatar
      Bug#37938 Test "mysqldump" lacks various INSERT statements / values · ef1d6cca
      Patrick Crews authored
      Moved fix for this bug to 5.0 as other mysqldump bugs seem tied to concurrent_insert being on
      Setting concurrent_insert off during this test as INSERTs weren't being 
      completely processed before the calls to mysqldump, resulting in failing tests.
      
      Altered .test file to turn concurrent_insert off during the test and to restore it
      to whatever the value was at the start of the test when complete.
      
      Re-recorded .result file to account for changes to variables in the test.
      ef1d6cca
    • Vladislav Vaintroub's avatar
      Bug#35987 - crash report on windows doesn't resolve stack traces. · 95af2754
      Vladislav Vaintroub authored
      The problem here is that symbols can not be loaded, because symbol
      path is not set and  default path does not include the directory
      where PDB is located.
      
      The problem is _not_ reproducible on the same machine where
      mysqld.exe is built - if PDB is not found in the symbol path,
      dbghelp would fallback to fully qualified PDB path as given in the
      executable header and on the build host this will succeed.
      
      The solution is to calculate symbol path and pass it to SymInitialize()
      call.
      95af2754
  9. 11 Sep, 2008 1 commit
  10. 10 Sep, 2008 2 commits
  11. 09 Sep, 2008 1 commit
  12. 05 Sep, 2008 3 commits
  13. 03 Sep, 2008 3 commits
    • Ramil Kalimullin's avatar
      Fix for bug#38821: Assert table->auto_increment_field_not_null failed · ef13c12c
      Ramil Kalimullin authored
      in open_table()
      
      Problem: repeating "CREATE... ( AUTOINCREMENT) ... SELECT" may lead to
      an assertion failure.
      
      Fix: reset table->auto_increment_field_not_null after each record 
      writing.
      ef13c12c
    • Gleb Shchepa's avatar
      merge with local tree · cfb4a66a
      Gleb Shchepa authored
      cfb4a66a
    • Gleb Shchepa's avatar
      Bug #39002: The server crashes on the query: · 6f94324f
      Gleb Shchepa authored
        INSERT .. SELECT .. ON DUPLICATE KEY UPDATE col=DEFAULT
      
      In order to get correct values from update fields that
      belongs to the SELECT part in the INSERT .. SELECT .. ON
      DUPLICATE KEY UPDATE statement, the server adds referenced
      fields to the select list. Part of the code that does this
      transformation is shared between implementations of
      the DEFAULT(col) function and the DEFAULT keyword (in
      the col=DEFAULT expression), and an implementation of
      the DEFAULT keyword is incomplete.
      6f94324f
  14. 01 Sep, 2008 4 commits
    • Vladislav Vaintroub's avatar
      Bug#37226 Explicit call of my_thread_init() on Windows for every new thread. · b2a49edd
      Vladislav Vaintroub authored
      Bug#33031 app linked to libmysql.lib crash if run as service in vista under 
      localsystem
        
      
      There are some problems using DllMain hook functions on Windows that 
      automatically do global and per-thread initialization for libmysqld.dll
      
      1)per-thread initialization(DLL_THREAD_ATTACH)
      MySQL internally counts number of active threads that and causes a delay in in 
      my_end() if not all threads are exited. But,there are threads that can be 
      started either by Windows internally (often in TCP/IP scenarios) or by user 
      himself - those threads are not necessarily using libmysql.dll functionality, 
      but nonetheless the contribute to the count of open threads.
      
      2)process-initialization (DLL_PROCESS_ATTACH)
      my_init() calls WSAStartup that itself loads DLLs and can lead to a deadlock in 
      Windows loader.
      
      Fix is to remove dll initialization code from libmysql.dll in general case. I
      still leave an environment variable LIBMYSQL_DLLINIT, which if set to any value 
      will cause the old behavior (DLL init hooks will be called). This env.variable 
      exists only to prevent breakage of existing Windows-only applications that 
      don't do mysql_thread_init() and work ok today. Use of LIBMYSQL_DLLINIT is 
      discouraged and it will be removed in 6.0
      b2a49edd
    • Davi Arnaut's avatar
      Restore tree name after merge from main. · 7e8c1374
      Davi Arnaut authored
      7e8c1374
    • Vladislav Vaintroub's avatar
      merge · 5334e5ae
      Vladislav Vaintroub authored
      5334e5ae
    • Mats Kindahl's avatar
      Merging in 5.0-rpl into 5.0-bugteam · 52141691
      Mats Kindahl authored
      52141691
  15. 29 Aug, 2008 1 commit
  16. 28 Aug, 2008 2 commits
  17. 27 Aug, 2008 3 commits
    • Gleb Shchepa's avatar
      Bug #37799: SELECT with a BIT column in WHERE clause · 2c53f109
      Gleb Shchepa authored
                  returns unexpected result
      
      If:
        1. a table has a not nullable BIT column c1 with a length
           shorter than 8 bits and some additional not nullable
           columns c2 etc, and
        2. the WHERE clause is like: (c1 = constant) AND c2 ...,
      the SELECT query returns unexpected result set.
      
      
      The server stores BIT columns in a tricky way to save disk
      space: if column's bit length is not divisible by 8, the
      server places reminder bits among the null bits at the start
      of a record. The rest bytes are stored in the record itself,
      and Field::ptr points to these rest bytes.
      
      However if a bit length of the whole column is less than 8,
      there are no remaining bytes, and there is nothing to store in
      the record at its regular place. In this case Field::ptr points
      to bytes actually occupied by the next column in a record.
      If both columns (BIT and the next column) are NOT NULL,
      the Field::eq function incorrectly deduces that this is the
      same column, so query transformation/equal item elimination
      code (see build_equal_items_for_cond) may mix these columns
      and damage conditions containing references to them.
      2c53f109
    • Joerg Bruehe's avatar
      Merge the bug fix development (37098: "unpackaged files") · 4cff4db3
      Joerg Bruehe authored
      into the 5.0 team tree.
      4cff4db3
    • Evgeny Potemkin's avatar
      Bug#38195: Incorrect handling of aggregate functions when loose index scan is · 1f28ee88
      Evgeny Potemkin authored
      used causes server crash.
            
      When the loose index scan access method is used values of aggregated functions
      are precomputed by it. Aggregation of such functions shouldn't be performed
      in this case and functions should be treated as normal ones.
      The create_tmp_table function wasn't taking this into account and this led to
      a crash if a query has MIN/MAX aggregate functions and employs temporary table
      and loose index scan.
      Now the JOIN::exec and the create_tmp_table functions treat MIN/MAX aggregate
      functions as normal ones when the loose index scan is used.
      1f28ee88
  18. 26 Aug, 2008 5 commits