grants are reapplied.


After renaming a user and trying to re-apply grants results in additional
grants.

This is because we use username as part of the key for GRANT_TABLE structure.
When the user is renamed, we only change the username stored and the hash key
still contains the old user name and this results in the extra privileges

Fixed by rebuilding the hash key and updating the column_priv_hash structure
when the user is renamed

mysql-test/r/grant3.result:
  Bug #41597 - After rename of user, there are additional grants when 
               grants are reapplied.
  
  Testcase for BUG#41597
mysql-test/t/grant3.test:
  Bug #41597 - After rename of user, there are additional grants when 
               grants are reapplied.
  
  Testcase for BUG#41597
sql/sql_acl.cc:
  Bug #41597 - After rename of user, there are additional grants when 
               grants are reapplied.
  
  Fixed handle_grant_struct() to update the hash key when the user is renamed.
  Added to set_user_details() method to GRANT_NAME class

can lead to bad memory access

Problem: Field_bit is the only field which returns INT_RESULT
and doesn't have unsigned flag. As it's not a descendant of the 
Field_num, so using ((Field_num *) field_bit)->unsigned_flag may lead
to unpredictable results.

Fix: check the field type before casting.


mysql-test/r/type_bit.result:
  Fix for bug #42803: Field_bit does not have unsigned_flag field,
  can lead to bad memory access
    - test result.
mysql-test/t/type_bit.test:
  Fix for bug #42803: Field_bit does not have unsigned_flag field,
  can lead to bad memory access
    - test case.
sql/opt_range.cc:
  Fix for bug #42803: Field_bit does not have unsigned_flag field,
  can lead to bad memory access
    - don't cast to (Field_num *) Field_bit, as it's not a Field_num
  descendant and is always unsigned by nature.

The pthread_cond_wait implementations for windows might
dead lock in some rare circumstances.

1) One thread (I) enter a timed wait and at a point in
   time ends up after mutex unlock and before
   WaitForMultipleObjects(...)
2) Another thread (II) enters pthread_cond_broadcast.
   Grabs the mutex and discovers one waiter. It set
   the broadcast event and closes the broadcast gate
   then unlocks the mutex.
3) A third thread (III) issues a pthread_cond_signal.
   It grabs the mutex, discovers one waiter, sets the
   signal event then unlock the mutex.
4) The first threads (I) enters WaitForMultipleObjects
   and finds out that the signal object is in a
   signalled state and exits the wait.
5) Thread (I) grabs the mutex and checks result status.
   The number of waiters is decreased and becomes equal
   to 0. The event returned was a signal event so the
   broadcast gate isn't opened. The mutex is released.
6) Thread (II) issues a new broadcast. The mutex is
   acquired but the number of waiters are 0 hence
   the broadcast gate remains closed.
7) Thread (I) enters the wait again but is blocked by
   the broadcast gate.

      This fix resolves the above issue by always resetting
      broadcast gate when there are no more waiters in th queue.


mysys/my_wincond.c:
  * Always reset the broadcast gate if there are no more waiters left.

                    Removes the need of a hack (the jump to label).

sql/sql_parse.cc:
  DBUG macros are wrapped inside a loop. Allow to break
  the command switch from within a DBUG macro.

On Mac OS X or Windows, sending a SIGHUP to the server or a
asynchronous flush (triggered by flush_time), would cause the
server to crash.

The problem was that a hook used to detach client API handles
wasn't prepared to handle cases where the thread does not have
a associated session.

The solution is to verify whether the thread has a associated
session before trying to detach a handle.

mysql-test/r/federated_debug.result:
  Add test case result for Bug#47525
mysql-test/t/federated_debug-master.opt:
  Debug point.
mysql-test/t/federated_debug.test:
  Add test case for Bug#47525
sql/slave.cc:
  Check whether a the thread has a associated session.
sql/sql_parse.cc:
  Add debug code to simulate a reload without thread session.

Make configure.js bail with an error if trying to build bdb from a bzr
tree.

          'flush tables' crashes

The server crashes when 'show procedure status' and 'flush tables' are
run concurrently.

This is caused by the way mysql.proc table is added twice to the list
of table to lock although the requirements on the current locking API
assumes differently.

No test case is submitted because of the nature of the crash which is 
currently difficult to reproduce in a deterministic way.

This is a backport from 5.1

myisam/mi_dbug.c:
  * check_table_is_closed is only used in EXTRA_DEBUG mode but since it is
  iterating over myisam shared data it still needs to be protected by an
  appropriate mutex.
sql/sql_yacc.yy:
  * Since the I_S mechanism is already handling the open and close of 
  mysql.proc there is no need for the method sp_add_to_query_tables.

The 'BEGIN/COMMIT/ROLLBACK' log event could be filtered out if the
database is not selected by --database option of mysqlbinlog command.
This can result in problem if there are some statements in the
transaction are not filtered out.

To fix the problem, mysqlbinlog will output 'BEGIN/ROLLBACK/COMMIT' 
in regardless of the database filtering rules.

client/mysqlbinlog.cc:
  Skip the database check for BEGIN/COMMIT/ROLLBACK log events.
mysql-test/r/mysqlbinlog.result:
  Test result for bug#46998
mysql-test/t/mysqlbinlog.test:
  Added test to verify if the 'BEGIN', 'COMMIT' and 'ROLLBACK' are output
  in regardless of database filtering

          replication
              
MySQL server uses wrong lock type (always TL_READ instead of
TL_READ_NO_INSERT when appropriate) for tables used in
subqueries of UPDATE statement. This leads in some cases to
a broken replication as statements are written in the wrong
order to the binlog.

sql/sql_yacc.yy:
  * Set lock_option to either TL_READ_NO_INSERT or
    TL_READ for any sub-SELECT following UPDATE.
  * Changed line adjusted for parser identation
    rules; code begins at column 13.

Add --help option.

   Solaris binary packages should be compiled with '-g0', not '-g'

 query
      
The fix for bug 46749 removed the check for OUTER_REF_TABLE_BIT 
and substituted it for a check on the presence of 
Item_ident::depended_from.
Removing it altogether was wrong : OUTER_REF_TABLE_BIT should 
still be checked in addition to depended_from (because it's not 
set in all cases and doesn't contradict to the check of depended_from).
Fixed by returning the old condition back as a compliment to the 
new one.

 - Create the "dummy" thread joinable and wait for it to
   exit before continuing in 'my_thread_global_init'
 - This way we know that the pthread library is initialized
   by one thread only

    Solaris binary packages should be compiled with '-g0', not '-g'

The main fix for this is done in the build tools,
but in the sources it affects "configure.in"
which sets "DEBUG_CXXFLAGS" to be used in all debug builds.

      
Initialize correctly client flags for the embedded client
Test cases in jp updated to work correctly with embedded server.

When parsing the service installation parameter in 
default_service_handling() make sure the value of the
optional parameter doesn't overwrite it's name.

with gcc 4.3.2
      
This is the fifth patch cleaning up more GCC warnings about
variables used before initialized using the new macro
UNINIT_VAR().

The problem is that argument buffer can be used as result buffer
and it leads to argument value change.
The fix is to use 'old buffer' as result buffer only
if first argument is not constant item.


mysql-test/r/func_str.result:
  test result
mysql-test/t/func_str.test:
  test case
sql/item_strfunc.cc:
  The problem is that argument buffer can be used as result buffer
  and it leads to argument value change.
  The fix is to use 'old buffer' as result buffer only
  if first argument is not constant item.

Updates the results of all the out-dated test suites and adds 
the special mysqltest command to enable innodb for the tests that need it.

            can crash under load

Backport from 5.1.
Does also include key cache fixes from:
Bug 44068 (RESTORE can disable the MyISAM Key Cache)
Bug 40944 (Backup: crash after myisampack)



include/keycache.h:
  Bug#17332 - changing key_buffer_size on a running server
              can crash under load
  Added KEY_CACHE components in_resize and waiting_for_resize_cnt.
myisam/mi_preload.c:
  Bug#17332 - changing key_buffer_size on a running server
              can crash under load
  Added code to allow LOAD INDEX to load indexes of different block size.
mysys/mf_keycache.c:
  Bug#17332 - changing key_buffer_size on a running server
              can crash under load
  .
  Changed resize_key_cache() to not disable the key cache
  after the flush phase. Changed queue handling to use
  standard functions. Wake all threads waiting on resize_queue.
  We can now have read/write threads waiting there (see below).
  .
  Combined add_to_queue() and the wait loops that were always
  following it to the new function wait_on_queue().
  Combined release_queue() and the condition that was always
  preceding it to the new function release_whole_queue().
  .
  Added code to flag and respect the exceptional situation
  BLOCK_IN_EVICTION.
  .
  Rewrote the resize branch of find_key_block().
  .
  Added code to the eviction handling in find_key_block()
  to catch more exceptional cases.
  .
  Changed key_cache_read(), key_cache_insert() and key_cache_write()
  so that they lock keycache->cache_lock whenever the key cache is
  initialized. Checking for a disabled cache and incrementing and
  decrementing the "resize counter" is always done within the lock.
  Locking and unlocking as well as counting the "resize counter" is
  now done once outside the loop. All three functions can now handle
  a NULL return from find_key_block. This happens in the flush phase
  of a resize and demands direct file I/O. Care is taken for
  secondary requests (PAGE_WAIT_TO_BE_READ) to wait in any case.
  Moved block status changes behind the copying of buffer data.
  key_cache_insert() does now read the block if the caller did
  supply less data than a full cache block.
  key_cache_write() does now take care of parallel running flushes
  (BLOCK_FOR_UPDATE, BLOCK_IN_FLUSHWRITE).
  .
  Changed free_block() to un-initialize block variables in the
  correct order and respect an exceptional BLOCK_IN_EVICTION state.
  .
  Changed flushing to take care for parallel running writes.
  Changed flushing to avoid freeing blocks in eviction.
  Changed flushing to consider that parallel writes can move blocks
  from the file_blocks hash to the changed_blocks hash.
  Changed flushing to take care for other parallel flushes.
  Changed flushing to assure that it ends with everything flushed.
  Optimized normal flush at end of statement (FLUSH_KEEP),
  but let other flush types be stringent.
  .
  Added some comments and debugging statements.
mysys/my_static.c:
  Bug#17332 - changing key_buffer_size on a running server
              can crash under load
  Removed an unused global variable.
sql/ha_myisam.cc:
  Bug#17332 - changing key_buffer_size on a running server
              can crash under load
  Moved an automatic (stack) variable to the scope where it is used.
sql/sql_table.cc:
  Bug#17332 - changing key_buffer_size on a running server
              can crash under load
  Changed TL_READ to TL_READ_NO_INSERT in mysql_preload_keys.

Memory allocated in TMP_TABLE_PARAM::copy_field is not cleaned up.
The fix is to clean up TMP_TABLE_PARAM::copy_field array in JOIN::destroy.


mysql-test/r/explain.result:
  test result
mysql-test/t/explain.test:
  test case
sql/sql_select.cc:
  Memory allocated in TMP_TABLE_PARAM::copy_field is not cleaned up.
  The fix is to clean up TMP_TABLE_PARAM::copy_field array in JOIN::destroy.

                    name as existing view

When trying to create a table with the same name as existing view with
join, mysql server crashes.

The problem is when create table is issued with the same name as view, while
verifying with the existing tables, we assume that base table object is 
created always.

In this case, since it is a view over multiple tables, we don't have the 
mysql derived table object.

Fixed the logic which checks if there is an existing table to not to assume
that table object is created when the base table is view over multiple 
tables.

mysql-test/r/create.result:
  BUG#46384 - mysqld segfault when trying to create table with same 
              name as existing view
  
  Testcase for the bug
mysql-test/t/create.test:
  BUG#46384 - mysqld segfault when trying to create table with same 
              name as existing view
  
  Testcase for the bug
sql/sql_insert.cc:
  BUG#46384 - mysqld segfault when trying to create table with same 
                  name as existing view
      
  Fixed create_table_from_items() method to properly check, if the base table 
  is a view over multiple tables.

                                for CREATE TABLE...LIKE...

Add my_sync.c to mysqltest sources list in CMakeLists.txt

client/CMakeLists.txt:
  BUG#46591 - .frm file isn't sync'd with sync_frm enabled
              for CREATE TABLE...LIKE...
  
  Add my_sync.c to mysqltest sources list

myisamchk tool generates warnings when run on an myisam files (.MYI or .MYD)
This is because of the conversion of max_value for certain options in myisamchk 
from singed long to unsigned long

The max value for the options key_buffer_size, read_buffer_size, write_buffer
_size and sort_buffer_size is given as (long) ~0L which becomes -1  when casted
from signed long to longlong and then casted to ulonglong. When (ulonglong) -1 
is compared with maximal value for GET_ULONG data type, we adjust it to 
(ulonglong) ULONG_MAX and throw the warning.

Fixed by using the right max size.

Max values for the variables (from mysqld.cc)
----------------------------
1. key_buffer_size
   5.0: ULONG_MAX
   5.1: SIZE_T_MAX
   6.0: SIZE_T_MAX

2. read_buffer_size and write_buffer_size
   5.0: INT_MAX32
   5.1: INT_MAX32
   6.0: INT_MAX32

3. sort_buffer_size (aka myisam_sort_buffer_size)
   5.0: UINT_MAX32
   5.1: ULONG_MAX
   6.0: ULONG_MAX

Note: testcase not attached

myisam/myisamchk.c:
  Bug#33785 - myisamchk show warning message
      
  Fixed the Max value for key_buffer_size, read_buffer_size, write_buffer_size and
  sort_buffer_size options