Bug #16604641: "SET PASSWORD FOR" CMD SUCCESS FOR USER PWD
 EXPIRED & FLAG NOT SET ACCORDINGLY

The expired flag in the thread specific copy of the user information 
was frivolously reset without first checking if the user whose password
is updated is the same user as in the thread cache.

Fixed by properly checking if the thread cache needs to be updated too
(together with the global user cache and the disk version).

Also fixed the omision to enforce the password expiration mode on 
SET PASSWORD FOR ... statement for cases where the password for
the current user is not reset.

Test case added.
Raise version number after cloning 5.6.12
Bug #16722314 FOREIGN KEY ID MODIFIED DURING EXPORT
Bug #16754901 PARS_INFO_FREE NOT CALLED IN DICT_CREATE_ADD_FOREIGN_TO_DICTIONARY

Problem:

There are two situations here.  The constraint name is explicitly
given by the user and the constraint name is automatically generated
by InnoDB.  In the case of generated constraint name, it is formed by
adding table name as prefix.  The table names are stored internally in
my_charset_filename.  In the case of constraint name explicitly given
by the user, it is stored in UTF8 format itself.  So, in some
situations the constraint name is in utf8 and in some situations it is
in my_charset_filename format.  Hence this problem.

Solution:

Always store the foreign key constraint name in UTF-8 even when
automatically generated.

Bug #16754901 PARS_INFO_FREE NOT CALLED IN DICT_CREATE_ADD_FOREIGN_TO_DICTIONARY

Problem:

There was a memory leak in the function dict_create_add_foreign_to_dictionary().
The allocated pars_info_t object is not freed in the error code path.

Solution:

Allocate the pars_info_t object after the error checking.

rb#2368 in review
Bug#16765255 Bug#16735660 ASSERT TABLE2 == NULL NOT FIXED COMPLETELY

Fix a regression introduced by
Bug#16593427 ROLLBACK OF RECOVERED TRANSACTION CORRUPTS CREATE INDEX

The fix in Bug#16735660 was incomplete.

Approved on IM by Jimmy Yang.
Merge from mysql-5.1 to mysql-5.5
Bug#16757869: INNODB: POSSIBLE REGRESSION IN 5.5.31, BUG#16004999

The problem was that if UPDATE with subselect caused a
deadlock inside InnoDB, this deadlock was not properly
handled by the SQL layer. This meant that the SQL layer
would try to unlock the row after InnoDB had rolled
back the transaction. This caused an assertion inside
InnoDB.
  
This patch fixes the problem by checking for errors
reported by SQL_SELECT::skip_record() and not calling
unlock_row() if any errors have been reported.

This bug is similar to Bug#13586591, but for UPDATE
rather than DELETE. Similar issues in filesort/opt_range/
sql_select will be investigated and handled in the scope
of Bug#16767929
Merge from mysql-5.5 to mysql-5.6
Updated spec file for Bug16488773
Bug#16757869: INNODB: POSSIBLE REGRESSION IN 5.5.31, BUG#16004999

The problem was that if UPDATE with subselect caused a
deadlock inside InnoDB, this deadlock was not properly
handled by the SQL layer. This meant that the SQL layer
would try to unlock the row after InnoDB had rolled
back the transaction. This caused an assertion inside
InnoDB.

This patch fixes the problem by checking for errors
reported by SQL_SELECT::skip_record() and not calling
unlock_row() if any errors have been reported.
  
This bug is similar to Bug#13586591, but for UPDATE
rather than DELETE. Similar issues in filesort/opt_range/
sql_select will be investigated and handled in the scope
of Bug#16767929
Merge from mysql-5.5 to mysql-5.6
Merge from mysql-5.1 to mysql-5.5
Null merge from mysql-5.5 to mysql-5.6
Bug #16722314 FOREIGN KEY ID MODIFIED DURING EXPORT
Bug #16754901 PARS_INFO_FREE NOT CALLED IN DICT_CREATE_ADD_FOREIGN_TO_DICTIONARY

Merging the fix from mysql-5.5 to mysql-5.5.32-release.
Merging the changes from 5.1 branch to release branch.
Includes bug fixes for:
Bug #16722314 FOREIGN KEY ID MODIFIED DURING EXPORT
Bug #16754901 PARS_INFO_FREE NOT CALLED IN DICT_CREATE_ADD_FOREIGN_TO_DICTIONARY
Updated spec file to ignore upgrade error message
BUG#16223835: UNEXPECTED EMPTY RESULTS OUT OF SHOW COMMANDS AFTER DUP GTID_NEXT TRANSACTION

When a transaction was skipped due to its GTID was already logged,
until GTID_NEXT was set to a different GTID, all the following
executed transactions were incorrectly skipped.

To avoid this incorrect behaviour, all executed transactions and
skipped transactions on AUTOCOMMIT=0 mode or which implicit commit
are marked as undefined (GTID_NEXT.type = UNDEFINED_GROUP) when them
commit or rollback. So when a second transaction is executed for the
same SET @@SESSION.GTID_NEXT command a error is thrown.
Bug#16513588:"PREPARE_COMMIT_MUTEX" IS NOT FREED DURING
TRANSACTION ROLLBACK

Problem:
=======
"prepare_commit_mutex" is acquired during "innobase_xa_prepare"
and it is freed only in "innobase_commit". After prepare,
if the commit operation fails the transaction is rolled back
but the mutex is not released.

Analysis:
========
During transaction commit process transaction is prepared and
the "prepare_commit_mutex" is acquired to preserve the order
of commit. After prepare write to binlog is initiated.

File: sql/handler.cc
      if (error || (is_real_trans && xid &&
----->             (error= !(cookie= tc_log->log_xid(thd, xid)))))
      {
        ha_rollback_trans(thd, all);

In the above code "tc_log->log_xid" operation fails.

When the write to binlog fails the transaction is rolled back
with out freeing the mutex. A subsequent "INSERT" operation
tries to acquire the same mutex during its commit process
and the server aborts.

Fix:
===
"prepare_commit_mutex" is freed during "innobase_rollback".
Null Merge from mysql-5.5 to mysql-5.6
Bug#16095534 CRASH: PREPARED STATEMENT CRASHES IN ITEM_BOOL_FUNC2::FIX_LENGTH_AND_DEC
The problem happened due to broken left expression in Item_in_optimizer object.
In case of the bug left expression is runtime created Item_outer_ref item which
is deleted at the end of the statement and one of Item_in_optimizer arguments
becomes bad when re-executed. The fix is to use real_item() instead of original
left expression. Note: It feels a bit weird that after preparing, the field is
directly part of the generated Item_func_eq, whereas in execution it is replaced
with an Item_outer_ref wrapper object.
5.1 -> 5.5 merge