of the stored procedure cursors (materialized on disk).


include/mysql_com.h:
  Remove an unused variable.
sql/protocol.cc:
  net->no_send_eof was not used anywhere.

into  moksha.com.br:/Users/davi/mysql/mysql-5.1-runtime

into  moksha.com.br:/Users/davi/mysql/mysql-5.1-runtime


sql/sql_handler.cc:
  Auto merged

If mysql_lock_tables fails because the lock was aborted, we need to
reset thd->some_tables_delete, otherwise we might loop indefinitely
because handler's tables are not closed in a standard way, meaning
that close_thread_tables() (which resets some_tables_deleted) is not
used.

This patch fixes sporadical failures of handler_myisam/innodb tests
which were introduced by previous fix for this bug.


sql/sql_handler.cc:
  Properly reset thd->some_tables_deleted if mysql_lock_tables
  fails for some reason.

into  weblab.(none):/home/marcsql/TREE/mysql-5.1-27858-b


mysql-test/r/log_tables.result:
  Auto merged

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)

"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.

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.

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

into  moksha.com.br:/Users/davi/mysql/bugs/31409-5.1


sql/sql_base.cc:
  Auto merged
sql/sql_handler.cc:
  Auto merged

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

into  moksha.com.br:/Users/davi/mysql/mysql-5.1-runtime


sql/sql_parse.cc:
  Post merge fix, the do_command prototype doesn't exist anymore.

into  moksha.com.br:/Users/davi/mysql/mysql-5.1-runtime


sql/sql_parse.cc:
  Auto merged

into  moksha.com.br:/Users/davi/mysql/mysql-5.1-runtime


mysql-test/r/sp.result:
  Auto merged
mysql-test/t/sp.test:
  Auto merged
sql/sql_parse.cc:
  Auto merged

into  moksha.com.br:/Users/davi/mysql/mysql-5.1-runtime

into  moksha.com.br:/Users/davi/mysql/mysql-5.1-runtime

mysql-test/include/handler.inc:
  Add test case for Bug 21587
mysql-test/r/handler_innodb.result:
  Add test case result for InnoDB run of the handler test for Bug 21587
mysql-test/r/handler_myisam.result:
  Add test case result for MyISAM run of the handler test for Bug 21587

into  moksha.com.br:/Users/davi/mysql/bugs/21587-5.1


sql/sql_handler.cc:
  Auto merged

of SQL_BIG_SELECTS.

The bug was that SQL_BIG_SELECTS was not properly set
in COM_CHANGE_USER.

The fix is to update SQL_BIG_SELECTS properly.


sql/mysql_priv.h:
  Cleanup: make prepare_new_connection_state() private for module.
sql/sql_class.cc:
  Update THD::options with the respect to SQL_BIG_SELECTS
  in COM_CHANGE_USER.
sql/sql_connect.cc:
  Cleanup: make prepare_new_connection_state() private for module.
tests/mysql_client_test.c:
  Add a test case BUG#20023.

into  station.:/mnt/raid/alik/MySQL/devel/5.1-rt-merged


mysql-test/t/sp.test:
  Merge.
sql/item_func.cc:
  Merge.

libmysqld/lib_sql.cc:
  Fixed packet length for embedded

into  moksha.com.br:/Users/davi/mysql/push/bugs/31409-5.0

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.

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

into  station.:/mnt/raid/alik/MySQL/devel/5.1-rt-merged


sql/mysql_priv.h:
  Auto merged
sql/sql_parse.cc:
  Manual merge/

mysql-test/t/upgrade.test:
  Test cleanup, --exec mkdir does not work on windows platforms

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

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.

into  pilot.mysql.com:/data/msvensson/mysql/my50-r-bug30992

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.

into  moksha.local:/Users/davi/mysql/push/mysql-5.0-runtime

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.

into  trift2.:/MySQL/M51/push-5.1


storage/ndb/test/ndbapi/testScanFilter.cpp:
  Auto merged

into  trift2.:/MySQL/M50/push-5.0

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().

into  production.mysql.com:/usersnfs/jperkin/bk/build/5.1


mysql-test/mysql-test-run.pl:
  Auto merged
scripts/mysql_install_db.sh:
  Auto merged