1. 11 Oct, 2006 1 commit
    • unknown's avatar
      BUG#22562 - REPAIR TABLE .. USE_FRM causes server crash on Windows and server · 31754c57
      unknown authored
                  hangs on Linux
      
      If REPAIR TABLE ... USE_FRM is issued for table that is located in different
      than default database server crash could happen.
      
      In reopen_name_locked_table take database name from table_list (user specified
      or default database) instead of from thd (default database).
      
      Affects 4.1 only.
      
      
      mysql-test/r/repair.result:
        A test case for BUG#22562.
      mysql-test/t/repair.test:
        A test case for BUG#22562.
      sql/sql_base.cc:
        In reopen_name_locked_table take database name from table_list (user specified
        or default database) instead of from thd (default database).
      31754c57
  2. 08 Oct, 2006 1 commit
  3. 06 Oct, 2006 4 commits
  4. 05 Oct, 2006 3 commits
    • unknown's avatar
      Merge svojtovich@bk-internal.mysql.com:/home/bk/mysql-4.1-engines · 9387a593
      unknown authored
      into  mysql.com:/home/svoj/devel/mysql/BUG21381/mysql-4.1-engines
      
      
      9387a593
    • unknown's avatar
      BUG#21381 - Engine not notified about multi-table UPDATE IGNORE · 2268afed
      unknown authored
      Though this is not storage engine specific problem, I was able to
      repeat this problem with BDB and NDB engines only. That was the
      reason to add a test case into ndb_update.test. As a result
      different bad things could happen.
      
      BDB has removed duplicate rows which is not expected.
      NDB returns an error.
      
      For multi table update notify storage engine about UPDATE IGNORE
      as it is done in single table UPDATE.
      
      
      mysql-test/r/ndb_update.result:
        A test case for bug#21381.
      mysql-test/t/ndb_update.test:
        A test case for bug#21381.
      sql/sql_update.cc:
        For multi table update notify storage engine about UPDATE IGNORE
        as it is done in single table UPDATE.
      2268afed
    • unknown's avatar
      Merge mysql.com:/home/gluh/MySQL/Merge/4.1 · 287b027e
      unknown authored
      into  mysql.com:/home/gluh/MySQL/Merge/4.1-kt
      
      
      include/m_ctype.h:
        Auto merged
      mysql-test/r/ctype_utf8.result:
        Auto merged
      mysql-test/t/ctype_utf8.test:
        Auto merged
      sql/table.cc:
        Auto merged
      sql/unireg.cc:
        Auto merged
      287b027e
  5. 03 Oct, 2006 7 commits
  6. 02 Oct, 2006 13 commits
  7. 30 Sep, 2006 3 commits
  8. 29 Sep, 2006 5 commits
  9. 28 Sep, 2006 3 commits
    • unknown's avatar
      Merge rolltop.ignatz42.dyndns.org:/mnt/storeage/bug20305/my41-bug20305 · 1bb27aea
      unknown authored
      into  rolltop.ignatz42.dyndns.org:/mnt/storeage/mysql-4.1-maint
      
      
      1bb27aea
    • unknown's avatar
      Fix for bug#22338 "Valgrind warning: uninitialized variable in · 5d46e299
      unknown authored
      create_tmp_table()".
      
      The fix for bug 21787 "COUNT(*) + ORDER BY + LIMIT returns wrong
      result" introduced valgrind warnings which occured during execution
      of information_schema.test and sp-prelocking.test in version 5.0.
      There were no user visible effects.
      
      The latter fix made create_tmp_table() dependant on
      THD::lex::current_select value. Valgrind warnings occured when this
      function was executed and THD::lex::current_select member pointed
      to uninitialized SELECT_LEX instance.
      
      This fix tries to remove this dependancy by moving some logic
      outside of create_tmp_table() function.
      
      
      sql/sql_select.cc:
        create_tmp_table():
          Moved code which is responsible for determining if optimization
          which pushes down LIMIT clause to temporary table creation is
          applicable out of this function.
          Such move made this function independant of THD::lex::current_select
          value and removed valgrind warnings which occured in cases when this
          member pointed to uninitialized SELECT_LEX object (particularly these
          warnings occured in sp-prelocking.test and information_schema.test
          in 5.0). This seems like a better solution than trying to force this
          pointer always to point to relevant select because:
          - In some cases when we use create_tmp_table() there are no relevant
            SELECT_LEX object (we use it just to create temporary table/object).
          - There is only one place in code where we call this funciton and
            where this optimization can be enabled. And in this place we
            already have some logic which tries to determine if it is applicable.
      5d46e299
    • unknown's avatar
      Merge chilla.local:/home/mydev/mysql-4.0-bug22384 · 03b88a48
      unknown authored
      into  chilla.local:/home/mydev/mysql-4.1-bug22384
      
      
      myisam/mi_delete.c:
        Auto merged
      03b88a48