sql/sql_show.h:
  Remove an unused declaration.

No conflicts

to fix an sp-error.test failure on Sun Sparc system.

for --init-rpl-role.

Problem: There are two variables involved in this issue,
rpl_status and rpl_role_type. The former is an array containing
the description of the possible values for the latter.

rpl_status is declared as an enumeration and is stored in a 4
bytes integer. On the other hand, my_getopt, reads enum values
into a ulong:

  *(ulong*)value= arg;

This is overwriting the memory used for rpl_role_type, 
corrupting the first entry in the array.

Fix: We fix this by re-declaring rpl_status as a ulong, so that it
has space to accommodate the value "parsed" in my_getopt .

with concurrent lock/unlock tables

Approved by Marko

The bug happened only on 5.1

After ALTER TABLE which changed only table's metadata, row-based
binlog sometimes got corrupted since the tablemap was unexpectedly
set to 0 for subsequent updates to the same table.

ALTER TABLE which changed only table's metadata always reset
table_map_id for the table share to 0. Despite the fact that
0 is a valid value for table_map_id, this step caused problems
as it could have created situation in which we had more than
one table share with table_map_id equal 0. If more than one
table with table_map_id are 0 were updated in the same statement,
updates to these different tables were written into the same
rows event. This caused slave server to crash.

This bug happens only on 5.1. It doesn't affect 5.5+.

This patch solves this problem by ensuring that ALTER TABLE
statements which change metadata only never reset table_map_id
to 0. To do this it changes reopen_table() to correctly use
refreshed table_map_id value instead of using the old one/
resetting it.


mysql-test/suite/rpl/r/rpl_alter.result:
  Add test for BUG#56226
mysql-test/suite/rpl/t/rpl_alter.test:
  Add test for BUG#56226

Removed option file and changed result file.

Print an error message to stderr an get rid of the assertion.

Approved by: Jimmy Yang (over IM)

When slave executes a transaction bigger than slave's max_binlog_cache_size,
slave will crash. It is caused by the assert that server should only roll back
the statement but not the whole transaction if the error ER_TRANS_CACHE_FULL 
happens. But slave sql thread always rollbacks the whole transaction when
an error happens.
            
Ather this patch, we always clear any error set in sql thread(it is different
from the error in 'SHOW SLAVE STATUS') and it is cleared before rolling back
the transaction.


mysql-test/suite/rpl/r/rpl_binlog_max_cache_size.result:
  SET binlog_cache_size and max_binlog_cache_size for all test cases.
  Add test case for bug#55375.
mysql-test/suite/rpl/t/rpl_binlog_max_cache_size-master.opt:
  binlog_cache_size and max_binlog_cache_size can be set in the client connection.
  so remove this option file.
mysql-test/suite/rpl/t/rpl_binlog_max_cache_size.test:
  SET binlog_cache_size and max_binlog_cache_size for all test cases.
  Add test case for bug#55375.
sql/log_event.cc:
  Some functions don't return the error code, so it is a wrong error code.
  The error should always be set into thd->main_da. So we use 
  slave_rows_error_report to report the right error.
sql/slave.cc:
  exec_relay_log_event() need call cleanup_context() to clear context. 
  clearup_context() will call end_trans().
          
  Clear thd's error before cleanup_context. It avoid to trigger the assert
  which cause this bug.

mysql-5.5-runtime tree.

Fix assorted compiler warnings.

sql/mysqld.cc:
  Do not declare max_page_size twice. If large pages support
  is enabled, the code expects the size in max_desired_page_size.
storage/innobase/include/ibuf0ibuf.h:
  Remove trailing comma. Only present in C99.
  
  Approved by: Vasil (via IRC)
storage/innobase/include/row0row.h:
  Remove trailing comma. Only present in C99.
  
  Approved by: Vasil (via IRC)
strings/my_vsnprintf.c:
  No need to assert the obvious.

 Bug#55744 GROUP_CONCAT + CASE + ucs return garbage
revealed problems in how character set aggregation
code works with prepared statements.

This patch fixes (hopefully) the problems.

Due to the extent of aliasing violations in the MySQL source
code, at this time it is safer to disable strict aliasing related
optimizations in release builds.

As of this patch, only GCC enables strict aliasing by default.
Hence, use the -fno-strict-aliasing option to disable the
aliasing rules.

cmake/build_configurations/mysql_release.cmake:
  Add -fno-strict-aliasing to release builds.

Adding a comment to scheduler_types on
the default values used.

The server contained code for the server variable and
option thread_pool_size, but this server variable where
not used anywhere.

The variable is probably remains from backporting too
much from 6.0 (specifically, the thread pool
implementation was not backported from 6.0, which this
variable is associated with).

This patch eliminates the variable from the server.

Only wait for a single debug signal at a time as the signal state
is global. Also, do not activate the query cache debug sync points
if the thread has no associated THD session.

mysql-test/t/query_cache_debug.test:
  Only wait for a single debug signal at a time as the signal state
  is global.
sql/sql_cache.cc:
  Do not execute the debug sync point if the thread has no associated
  THD session. This scenario happens for federated threads.

Buffer overrun when trying to format DBL_MAX


mysql-test/r/func_math.result:
  Add test case for Bug#57209
mysql-test/t/func_math.test:
  Add test case for Bug#57209
sql/item_strfunc.cc:
  Allocate a larger buffer for the result.

In calvin.sun@oracle.com-20101005183830-p81bemgffq8l2en9 the default
value of innodb_file_per_table was changed from 1 to 0.

engine is not available. We need to add loose prefix
to example load option.

        now do no initializations for the --help.
        Do it for --verbose --help though.

per-file comments:
  sql/mysqld.cc
Bug#30025 Mysqld prints out warnings/errors being run with --no-defaults --help
        quit with the help message at once as --help was given

        Issue an error if user specifies multiple commands to run.
        Also there was an unnoticed bug that DO_CHECK was actually 0 which lead
        to wrong actions in some cases.
        The mysqlcheck.test contained commands with the suspicious meaning
        for the above reason. Extra commands removed from there.

per-file commands:
  client/mysqlcheck.c
Bug#35269      mysqlcheck behaves different depending on order of parameters
        Drop with an error if multiple commands.
  mysql-test/r/mysqlcheck.result
Bug#35269      mysqlcheck behaves different depending on order of parameters
        result completed.
  mysql-test/t/mysqlcheck.test
Bug#35269      mysqlcheck behaves different depending on order of parameters
        testcase added.
        not-working commands removed from some mysqlcheck calls.

Fix warnings related to the use of the deprecated gets() function
and passing NULL to non-pointer argument of the sys_var constructor.

plugin/auth/dialog.c:
  Do not use the deprecated gets() function.
sql/sys_vars.h:
  Do not pass NULL to a non-pointer argument of the sys_var constructor.

Move Query_cache_wait_state declaration out of a debug block.

The problem was that threads waiting on the query cache lock
are not easily seen due to the lack of a state indicating that
the thread is waiting on the said lock. This made it difficult
for users to quickly spot (for example, via SHOW PROCESSLIST)
a query cache contention problem.

The solution is to update the thread state when the query cache
lock needs to be acquired. Whenever the lock is to be acquired,
the thread state is updated to "Waiting for query cache lock"
and is reset once the lock is granted or the wait is interrupted.
The intention is to make query cache related hangs more evident.

To further investigate query cache related locking problems, one
may use PERFORMANCE_SCHEMA to track the overhead associated with
the locking bits and determine which particular lock is being a
contention point.

sql/sql_cache.cc:
  Set and reset the thread state whenever a attempt to lock the
  query cache is made.
  
  Use DEBUG_SYNC instead of the now unnecessary wait_for_kill hack.

The coalesce function returned DATETIME type due to a DATETIME argument, but
since it's not a date/time function it can't return correct int value for
it. Nevertheless Item_datetime_cache was chosen to cache coalesce's result
and that led to a wrong result.

Now Item_datetime_cache is used only for those function that could return
correct int representation of DATETIME values.


mysql-test/r/type_datetime.result:
  Added a test case for the bug#57095.
mysql-test/t/type_datetime.test:
  Added a test case for the bug#57095.
sql/item.cc:
  Bug#57095: Wrongly chosen expression cache type led to a wrong result.
  Now Item_datetime_cache is used only for those function that could return
  correct int representation of DATETIME values.

discover its existence".

The problem was that user without any privileges on 
routine was able to find out whether it existed or not.
DROP FUNCTION and DROP PROCEDURE statements were 
checking if routine being dropped existed and reported 
ER_SP_DOES_NOT_EXIST error/warning before checking 
if user had enough privileges to drop it.

This patch solves this problem by changing code not to 
check if routine exists before checking if user has enough 
privileges to drop it. Moreover we no longer perform this 
check using a separate call instead we rely on 
sp_drop_routine() returning SP_KEY_NOT_FOUND if routine 
doesn't exist.

This change also simplifies one of upcoming patches
refactoring global read lock implementation.

mysql-test/r/grant.result:
  Updated test case after fixing bug#57061 "User without
  privilege on routine can discover its existence". Removed
  DROP PROCEDURE/FUNCTION statements which have started to
  fail after this fix (correctly). There is no need in
  dropping routines in freshly created database anyway.
mysql-test/r/sp-security.result:
  Added new test case for bug#57061 "User without privilege
  on routine can discover its existence". Updated existing
  tests according to new behaviour.
mysql-test/suite/funcs_1/r/innodb_storedproc_06.result:
  Updated test case after fixing bug#57061 "User without
  privilege on routine can discover its existence".
  Now we drop routines under user which has enough
  privileges to do so.
mysql-test/suite/funcs_1/r/memory_storedproc_06.result:
  Updated test case after fixing bug#57061 "User without
  privilege on routine can discover its existence".
  Now we drop routines under user which has enough
  privileges to do so.
mysql-test/suite/funcs_1/r/myisam_storedproc_06.result:
  Updated test case after fixing bug#57061 "User without
  privilege on routine can discover its existence".
  Now we drop routines under user which has enough
  privileges to do so.
mysql-test/suite/funcs_1/storedproc/storedproc_06.inc:
  Updated test case after fixing bug#57061 "User without
  privilege on routine can discover its existence".
  Now we drop routines under user which has enough
  privileges to do so.
mysql-test/t/grant.test:
  Updated test case after fixing bug#57061 "User without
  privilege on routine can discover its existence". Removed
  DROP PROCEDURE/FUNCTION statements which have started to
  fail after this fix (correctly). There is no need in
  dropping routines in freshly created database anyway.
mysql-test/t/sp-security.test:
  Added new test case for bug#57061 "User without privilege
  on routine can discover its existence". Updated existing
  tests according to new behaviour.
sql/sp.cc:
  Removed sp_routine_exists_in_table() which is no longer
  used.
sql/sp.h:
  Removed sp_routine_exists_in_table() which is no longer
  used.
sql/sql_parse.cc:
  When dropping routine we no longer check if routine exists 
  before checking if user has enough privileges to do so. 
  Moreover we no longer perform this check using a separate 
  call instead we rely on sp_drop_routine() returning 
  SP_KEY_NOT_FOUND if routine doesn't exist.