1. 15 Oct, 2007 2 commits
  2. 12 Oct, 2007 3 commits
  3. 11 Oct, 2007 7 commits
    • unknown's avatar
      Merge malff@bk-internal.mysql.com:/home/bk/mysql-5.1-runtime · fba72eb8
      unknown authored
      into  weblab.(none):/home/marcsql/TREE/mysql-5.1-27858-b
      
      
      mysql-test/r/log_tables.result:
        Auto merged
      fba72eb8
    • unknown's avatar
      Bug#27858 (Failing to log to a log table doesn't log anything to error log) · 411eba91
      unknown authored
      Before this patch, failures to write to the log tables (mysql.slow_log
      and mysql.general_log) were improperly printed (the time was printed twice),
      or not printed at all.
      
      With this patch, failures to write to the log tables is reported in the
      error log, for all cases of failures.
      
      
      mysql-test/r/log_tables.result:
        Bug#27858 (Failing to log to a log table doesn't log anything to error log)
      mysql-test/t/log_tables.test:
        Bug#27858 (Failing to log to a log table doesn't log anything to error log)
      sql/log.cc:
        Bug#27858 (Failing to log to a log table doesn't log anything to error log)
      411eba91
    • unknown's avatar
      Bug#29223 declare cursor c for SHOW ..... · 2170dd08
      unknown authored
      "DECLARE CURSOR FOR SHOW ..." is a syntax that currently appears to work,
      but is untested for some SHOW commands and does not work for other SHOW
      commands.
      
      Since this is an un-intended feature that leaked as a result of a coding bug
      (in the parser grammar), the correct fix is to fix the grammar to not accept
      this construct.
      
      In other words, "DECLARE CURSOR FOR SHOW <other commands that don't work>"
      is not considered a bug, and we will not implement other features to make all
      the SHOW commands usable inside a cursor just because someone exploited a bug.
      
      
      mysql-test/r/sp-error.result:
        Only allow declaring cursors for SELECT statements to avoid
        possible further confusion/problems.
      mysql-test/t/information_schema.test:
        Only SELECT statements are allowed in cursors.
      mysql-test/t/sp-error.test:
        Add test case for Bug#29223. Non-SELECT statements in cursors now
        yields a parser error.
      sql/sql_yacc.yy:
        Rework DECLARE CURSOR statement to not allow non-SELECT statements.
      2170dd08
    • unknown's avatar
      A patch for BUG#31418: User locks misfunctioning after · 8d51a6a5
      unknown authored
      mysql_change_user().
      
      The problem was that THD::ull was not reset in THD::cleanup().
      
      The fix is to reset it.
      
      
      sql/sql_class.cc:
        Reset THD::ull after cleanup to prevent memory corruption.
      tests/mysql_client_test.c:
        Add test case for BUG#31418.
      8d51a6a5
    • unknown's avatar
      Post-merge test case for Bug 31409 · f8bc525a
      unknown authored
      
      mysql-test/include/handler.inc:
        Add test case for Bug 31409
      mysql-test/r/handler_innodb.result:
        Add test case result for InnoDB run of the handler test for Bug 31409
      mysql-test/r/handler_myisam.result:
        Add test case result for MyISAM run of the handler test for Bug 31409
      f8bc525a
    • unknown's avatar
      Merge moksha.com.br:/Users/davi/mysql/mysql-5.0-runtime · f7509e97
      unknown authored
      into  moksha.com.br:/Users/davi/mysql/bugs/31409-5.1
      
      
      sql/sql_base.cc:
        Auto merged
      sql/sql_handler.cc:
        Auto merged
      f7509e97
    • unknown's avatar
      Mismerge broken 5.1-runtime compilation because do_command was defined · 6899d5ce
      unknown authored
      static but it's still used by another compilation unit.
      
      Remove static qualifier from do_command definition.
      
      
      sql/sql_parse.cc:
        do_command is also used by sql_connect.c in 5.1
      6899d5ce
  4. 10 Oct, 2007 11 commits
  5. 09 Oct, 2007 5 commits
    • unknown's avatar
      Merge moksha.com.br:/Users/davi/mysql/push/mysql-5.0-runtime · be03ccb8
      unknown authored
      into  moksha.com.br:/Users/davi/mysql/push/bugs/31409-5.0
      
      be03ccb8
    • unknown's avatar
      Bug#31409 RENAME TABLE causes server crash or deadlock when used with HANDLER statements · dc83df33
      unknown authored
      This deadlock occurs when a client issues a HANDLER ... OPEN statement
      that tries to open a table that has a pending name-lock on it by another
      client that also needs a name-lock on some other table which is already
      open and associated to a HANDLER instance owned by the first client.
      The deadlock happens because the open_table() function will back-off
      and wait until the name-lock goes away, causing a circular wait if some
      other name-lock is also pending for one of the open HANDLER tables.
      
      Such situation, for example, can be easily repeated by issuing a RENAME
      TABLE command in such a way that the existing table is already open
      as a HANDLER table by another client and this client tries to open
      a HANDLER to the new table name.
      
      The solution is to allow handler tables with older versions (marked for
      flush) to be closed before waiting for the name-lock completion. This is
      safe because no other name-lock can be issued between the flush and the
      check for pending name-locks.
      
      The test case for this bug is going to be committed into 5.1 because it
      requires a test feature only avaiable in 5.1 (wait_condition).
      
      
      sql/sql_base.cc:
        Improve comments in the open_table() function, stating the importance
        of the handler tables flushing for the back-off process.
      sql/sql_handler.cc:
        Allows handler tables flushes when opening new tables in order to avoid
        potential deadlocks. Add comments explaining the importance of the flush.
      dc83df33
    • unknown's avatar
      Merge moksha.local:/Users/davi/mysql/push/mysql-5.0-runtime · d0483067
      unknown authored
      into  moksha.local:/Users/davi/mysql/push/mysql-5.1-runtime
      
      
      include/config-win.h:
        Auto merged
      include/my_pthread.h:
        Auto merged
      mysys/thr_mutex.c:
        Auto merged
      d0483067
    • unknown's avatar
      Fix merge. · e2e3760f
      unknown authored
      e2e3760f
    • unknown's avatar
      Merge station.:/mnt/raid/alik/MySQL/devel/5.0-rt · 675b1fca
      unknown authored
      into  station.:/mnt/raid/alik/MySQL/devel/5.1-rt-merged
      
      
      sql/mysql_priv.h:
        Auto merged
      sql/sql_parse.cc:
        Manual merge/
      675b1fca
  6. 08 Oct, 2007 3 commits
  7. 07 Oct, 2007 2 commits
    • unknown's avatar
      Merge bk-internal.mysql.com:/home/bk/mysql-5.0 · 5418f2a8
      unknown authored
      into  bodhi.(none):/opt/local/work/mysql-5.0-runtime
      
      
      mysql-test/r/sp.result:
        Auto merged
      mysql-test/t/sp.test:
        Auto merged
      sql/sql_parse.cc:
        Auto merged
      5418f2a8
    • unknown's avatar
      Merge bk-internal.mysql.com:/home/bk/mysql-5.1 · d5647356
      unknown authored
      into  bodhi.(none):/opt/local/work/mysql-5.1-runtime
      
      
      mysql-test/include/mix1.inc:
        Auto merged
      mysql-test/r/create.result:
        Auto merged
      mysql-test/r/innodb_mysql.result:
        Auto merged
      mysql-test/r/sp.result:
        Auto merged
      mysql-test/t/sp.test:
        Auto merged
      sql/sql_lex.h:
        Auto merged
      sql/sql_parse.cc:
        Auto merged
      sql/sql_select.cc:
        Auto merged
      sql/sql_yacc.yy:
        Auto merged
      libmysql/libmysql.c:
        Manual merge.
      d5647356
  8. 05 Oct, 2007 2 commits
    • unknown's avatar
      Merge bk-internal:/home/bk/mysql-5.0-runtime · 60672bb1
      unknown authored
      into  pilot.mysql.com:/data/msvensson/mysql/my50-r-bug30992
      
      60672bb1
    • unknown's avatar
      Fix for BUG#20550: Stored function: wrong RETURN type metadata · af0aaca4
      unknown authored
      when used in a VIEW.
      
      The problem was that wrong function (create_tmp_from_item())
      was used to create a temporary field for Item_func_sp.
      
      The fix is to use create_tmp_from_field().
      
      
      mysql-test/r/sp.result:
        Update result file.
      mysql-test/t/sp.test:
        Add a test case for BUG#20550.
      sql/item_func.h:
        Add a getter for Item_func_sp::sp_result_field.
      sql/sql_select.cc:
        Use create_tmp_from_field() to create a temporary field
        for Item_func_sp.
      af0aaca4
  9. 04 Oct, 2007 5 commits
    • unknown's avatar
      Merge bk-internal.mysql.com:/home/bk/mysql-5.0-runtime · 923f23e5
      unknown authored
      into  moksha.local:/Users/davi/mysql/push/mysql-5.0-runtime
      
      923f23e5
    • unknown's avatar
      Bug#21587 FLUSH TABLES causes server crash when used with HANDLER statements · 9db14715
      unknown authored
      This bug is a symptom of the way handler's tables are managed. The
      most different aspect, compared to the conventional behavior, is that
      the handler's tables are long lived, meaning that their lifetimes are
      not bounded by the duration of the command that opened them. For this
      effect the handler code uses its own list (handler_tables instead of
      open_tables) to hold open handler tables so that the tables won't be
      closed at the end of the command/statement. Besides the handler_tables
      list, there is a hash (handler_tables_hash) which is used to associate
      handler aliases to tables and to refresh the tables upon demand (flush
      tables).
      
      The current implementation doesn't work properly with refreshed tables
      -- more precisely when flush commands are issued by other initiators.
      This happens because when a handler open or read statement is being
      processed, the associated table has to be opened or locked and, for this
      matter, the open_tables and handler_tables lists are swapped so that the
      new table being opened is inserted into the handler_tables list. But when
      opening or locking the table, if the refresh version is different from the
      thread refresh version then all used tables in the open_tables list (now
      handler_tables) are refreshed. In the "refreshing" process the handler
      tables are flushed (closed) without being properly unlinked from the
      handler hash.
      
      The current implementation also fails to properly discard handlers of
      dropped tables, but this and other problems are going to be addressed
      in the fixes for bugs 31397 and 31409.
      
      The chosen approach tries to properly save and restore the table state
      so that no table is flushed during the table open and lock operations.
      The logic is almost the same as before with the list swapping, but with
      a working glue code.
      
      The test case for this bug is going to be committed into 5.1 because it
      requires a test feature only avaiable in 5.1 (wait_condition).
      
      
      sql/sql_handler.cc:
        Backup and reset the open_tables and handler_table lists when opening
        a new handler table and merge the opened table into the handler_tables
        list afterwards. When locking, do the same but possibly close the table
        if a refresh is pending.
      9db14715
    • unknown's avatar
      Merge trift2.:/MySQL/M50/push-5.0 · 0f769793
      unknown authored
      into  trift2.:/MySQL/M51/push-5.1
      
      
      storage/ndb/test/ndbapi/testScanFilter.cpp:
        Auto merged
      0f769793
    • unknown's avatar
      Merge trift2.:/MySQL/M50/mysql-5.0 · 711be53b
      unknown authored
      into  trift2.:/MySQL/M50/push-5.0
      
      711be53b
    • unknown's avatar
      Fix for BUG#31035: select from function, group by result crasher. · c6c68c45
      unknown authored
      This actually, fix for the patch for bug-27354. The problem with
      the patch was that Item_func_sp::used_tables() was updated, but
      Item_func_sp::const_item() was not. So, for Item_func_sp, we had
      the following inconsistency:
        - used_tables() returned RAND_TABLE, which means that the item
          can produce "random" results;
        - but const_item() returned TRUE, which means that the item is
          a constant one.
      
      The fix is to change Item_func_sp::const_item() behaviour: it must
      return TRUE (an item is a constant one) only if a stored function
      is deterministic and each of its arguments (if any) is a constant
      item.
      
      
      mysql-test/r/sp.result:
        Update result file.
      mysql-test/t/sp.test:
        Add test cases for BUG-31035, BUG-31191, BUG-31226
      sql/item_func.cc:
        Make Item::const_item() be consistent with Item::used_tables().
      c6c68c45