function privileges" into 5.5 tree. Did after-merge fixes.

function privileges" into 5.5 tree. Did after-merge fixes.

privileges".

The first problem was that DROP USER didn't properly remove privileges 
on stored functions from in-memory structures. So the dropped user
could have called stored functions on which he had privileges before
being dropped while his connection was still around.
Even worse if a new user with the same name was created he would
inherit privileges on stored functions from the dropped user.
Similar thing happened with old user name and function privileges
during RENAME USER.

This problem stemmed from the fact that the handle_grant_data() function
which handled DROP/RENAME USER didn't take any measures to update
in-memory hash with information about function privileges after
updating them on disk.

This patch solves this problem by adding code doing just that.

The second problem was that RENAME USER didn't properly update in-memory
structures describing table-level privileges and privileges on stored 
procedures. As result such privileges could have been lost after a rename
(i.e. not associated with the new name of user) and inherited by a new
user with the same name as the old name of the original user.

This problem was caused by code handling RENAME USER in
handle_grant_struct() which [sic!]:
a) tried to update wrong (tables) hash when updating stored procedure
   privileges for new user name.
b) passed wrong arguments to function performing the hash update and
   didn't take into account the way in which such update could have
   changed the order of the hash elements.

This patch solves this problem by ensuring that a) the correct hash
is updated, b) correct arguments are used for the hash_update()
function and c) we take into account possible changes in the order
of hash elements.

mysql-test/r/grant.result:
  Added test coverage for bug#36544 "DROP USER does not remove stored
  function privileges".
mysql-test/suite/funcs_1/r/innodb_storedproc_06.result:
  Since after fixing bug#36544 "DROP USER does not remove stored function
  privileges" in-memory structures are correctly updated by DROP USER,
  DROP FUNCTION performed after DROP USER for its definer no longer
  produces unwarranted warning/error messages.
mysql-test/suite/funcs_1/r/memory_storedproc_06.result:
  Since after fixing bug#36544 "DROP USER does not remove stored function
  privileges" in-memory structures are correctly updated by DROP USER,
  DROP FUNCTION performed after DROP USER for its definer no longer
  produces unwarranted warning/error messages.
mysql-test/suite/funcs_1/r/myisam_storedproc_06.result:
  Since after fixing bug#36544 "DROP USER does not remove stored function
  privileges" in-memory structures are correctly updated by DROP USER,
  DROP FUNCTION performed after DROP USER for its definer no longer
  produces unwarranted warning/error messages.
mysql-test/t/grant.test:
  Added test coverage for bug#36544 "DROP USER does not remove stored
  function privileges".
sql/sql_acl.cc:
  Changed handle_grant_data() to also update hash with function 
  privileges. This allows DROP/RENAME USER correctly keep this 
  in-memory structure up-to-date.
  
  To do this extended handle_grant_struct() to support updating of this
  hash. In addition fixed code in this function which is responsible for 
  handling of column and routine hashes during RENAME USER, ensured that
  we correctly update these hashes after changing user name and that we
  don't skip elements while iterating through the hash and doing updates.

Fixed the 'show profile source' part of the bug.
Leaving SHOW ENGINE INNODB MUTEX to a separate patch.



sql/sql_class.cc:
  Use base_name(calling_file) for dbug trace and profiling.

bug#57924 does not occur in 5.5, so I reverted the 5.1 specific
code and used the errors from 5.5 instead in the tests

           that implement add_index

The problem was that ALTER TABLE blocked reads on an InnoDB table
while adding a secondary index, even if this was not needed. It is
only needed for the final step where the .frm file is updated.

The reason queries were blocked, was that ALTER TABLE upgraded the
metadata lock from MDL_SHARED_NO_WRITE (which blocks writes) to
MDL_EXCLUSIVE (which blocks all accesses) before index creation.

The way the server handles index creation, is that storage engines
publish their capabilities to the server and the server determines
which of the following three ways this can be handled: 1) build a
new version of the table; 2) change the existing table but with
exclusive metadata lock; 3) change the existing table but without
metadata lock upgrade.

For InnoDB and secondary index creation, option 3) should have been
selected. However this failed for two reasons. First, InnoDB did
not publish this capability properly.

Second, the ALTER TABLE code failed to made proper use of the
information supplied by the storage engine. A variable
need_lock_for_indexes was set accordingly, but was not later used.
This patch fixes this problem by only doing metadata lock upgrade
before index creation/deletion if this variable has been set.

This patch also changes some of the related terminology used 
in the code. Specifically the use of "fast" and "online" with
respect to ALTER TABLE. "Fast" was used to indicate that an
ALTER TABLE operation could be done without involving a
temporary table. "Fast" has been renamed "in-place" to more
accurately describe the behavior.

"Online" meant that the operation could be done without taking
a table lock. However, in the current implementation writes
are always prohibited during ALTER TABLE and an exclusive
metadata lock is held while updating the .frm, so ALTER TABLE
is not completely online. This patch replaces "online" with 
"in-place", with additional comments indicating if concurrent
reads are allowed during index creation/deletion or not.

An important part of this update of terminology is renaming
of the handler flags used by handlers to indicate if index
creation/deletion can be done in-place and if concurrent reads
are allowed. For example, the HA_ONLINE_ADD_INDEX_NO_WRITES
flag has been renamed to HA_INPLACE_ADD_INDEX_NO_READ_WRITE,
while HA_ONLINE_ADD_INDEX is now HA_INPLACE_ADD_INDEX_NO_WRITE.
Note that this is a rename to clarify current behavior, the
flag values have not changed and no flags have been removed or
added.

Test case added to innodb_mysql_sync.test.

Fix backported from to 5.0.
"Remove the alignment option, let valgrind use its default"


mysql-test/mysql-test-run-shell.sh:
  Bug #47811 : remove the non-default alignment specification.
    - backport from 5.1
     "Remove the alignment option, let valgrind use its default"
mysql-test/mysql-test-run.pl:
  Bug #47811 : remove the non-default alignment specification.
    - backport from 5.1
     "Remove the alignment option, let valgrind use its default"

Updated the copyright.

Updated Copyright.

Race condition may occur: mtr sees the .expect file but it's empty
Fix: wait and try again if file is empty
Addendum: try again if line isn't 'wait' or 'restart'
Also added verbose printout of extra restart options

ZERO
      
When dates are represented internally as strings, i.e. when a string constant
is compared to a date value, both values are converted to long integers,
ostensibly for fast comparisons. DATE typed integer values are converted to
DATETIME by multiplying by 1,000,000 (each digit pair representing hour,
minute and second, respectively). But the mechanism did not distuinguish
cached INTEGER values, already in correct format, from newly converted
strings.

Fixed by marking the INTEGER cache as being of DATETIME format.