--BZR--
revision-id: mysql-builder@oracle.com-20120914134921-neg4e4jkbuzuv1ol
property-audit-revid: manish.4.kumar@oracle.com-20120914134921-u31e79sevff2cio2
property-branch-nick: clone
testament3-sha1: 98939b976323387eeb81429f80c9078919999895
Bug#14589559: ASSERTION `FILE_ENTRY_BUF[2] == 0'
FAILED IN DEACTIVATE_DDL_LOG_ENTRY

deallocate_ddl_log_entry() can be called without having
locked LOCK_gdl. It uses a global buffer for reading and
writing entries in the ddl_log, and since it is not protected
by any mutex, two concurrent threads can overwrite the
content in the global buffer, so it can be different from
what was read.
Thread a reads from entry 1 into global
buffer, thread b reads from entry 2 into global buffer,
thread a writes from global buffer into entry 1
-> entry 1 is not the content of entry 2.

This is especially bad for replace entries, which uses
two phases, and does not deactivate the whole entry
after the first phase, but increases the phase instead.

Fixed by using thread local storage (stack) instead of global
storage (global buffer).

Also added buffer and size arguments to
read/write_ddl_log_file_entry.

Also only read/write first bytes in entries in
deactivate_ddl_log_entry.

Also fixed the scenario where it will try to recover from a server
compiled with a different value of IO_SIZE (very uncommon!)

updated patch with set_ddl_log_entry_from_buf
and removed read_ddl_log_entry.

Manually tested, no test case included.
--BZR--
revision-id: mattias.jonsson@oracle.com-20121018095947-q53ri99fxc9tnddd
property-audit-revid: mattias.jonsson@oracle.com-20121018095947-rv11hpmz9rj4toc9
property-branch-nick: b14589559-51
testament3-sha1: ad93b611ead8fdeb4ed7a857121a4f51a95ea997
Manual merge of bug#14589559 from mysql-5.1 to 5.5
--BZR--
revision-id: mattias.jonsson@oracle.com-20121018102702-i0khpo2n7bdgc236
property-audit-revid: mattias.jonsson@oracle.com-20121018102702-vipftx5g4807ezps
property-branch-nick: b14589559-55_2
testament3-sha1: 41a249d705b86d93d697bdbddf7e0f08317dfa82
Raise version number after cloning 5.5.29
--BZR--
revision-id: hery.ramilison@oracle.com-20121103040609-sh52pkucuqspo59h
property-audit-revid: hery.ramilison@oracle.com-20121103040609-2gpss377xdlzvsyy
property-authors: hery.ramilison@oracle.com
property-branch-nick: mysql-5.5
testament3-sha1: cbac01df6de418ffa5c56814f5d4a4ccf6289f09
mtr.pl
 - improve the logic that decides when ndbcluster should be enabled and the extra
  test suites for MySQL Cluster should be added. Should be consistent and logical now ;)
--BZR--
revision-id: magnus.blaudd@oracle.com-20121104211134-f8bu8cwue2xpnslm
property-audit-revid: magnus.blaudd@oracle.com-20121104211134-oyn5w8hzo9joh84q
property-branch-nick: 5.5
testament3-sha1: a87e69be4f3848567890d3ace0d8e144aec7bd68
mtr.pl
 - remove unused hack to turn on extra suites based on current directory name
 - remove 4 your old debug printout of "vardir: <dir>"
--BZR--
revision-id: magnus.blaudd@oracle.com-20121104211717-lb44kh2x0ytllm37
property-audit-revid: magnus.blaudd@oracle.com-20121104211717-p2q3pcu876j7vvnl
property-branch-nick: 5.5
testament3-sha1: adcb0cb9957b930ea5854456af7b7f01640250cd
Raise version number after cloning 5.1.67
--BZR--
revision-id: akhil.mohan@oracle.com-20121105100546-t3npf6fxn8gn6p6c
property-audit-revid: akhil.mohan@oracle.com-20121105100546-wgf5k7u2kw8cfqg3
property-authors: akhil.mohan@oracle.com
property-branch-nick: mysql-5.1
testament3-sha1: 78897fd0708d04e73b07c8629bf3426fdca2158c
Version change upmerge - empty
--BZR--
revision-id: joerg.bruehe@oracle.com-20121105110805-0yh362fwdjczq44z
property-audit-revid: joerg.bruehe@oracle.com-20121105110805-w6bf1q8sbe7xl53k
property-branch-nick: mysql-5.5
testament3-sha1: 57a680649b960fbc48e8ecbe97c50aa0758df7d4


--BZR--
revision-id: mysql-builder@oracle.com-20121105121513-coddls5g1i90n53a
property-audit-revid: venkata.sidagam@oracle.com-20121105121513-1xvuqsuu1yd1z7nx
property-branch-nick: clone
testament3-sha1: 3234909264c4c621e3533dc8d3ce423a8a7fa7b6
Bug#11751825 - OPTIMIZE PARTITION RECREATES FULL TABLE INSTEAD JUST PARTITION

PROBLEM 
-------

optimize on partiton will recreate the whole table 
instead of just partition.

ANALYSIS
--------

At present innodb doesn't support optimize option ,so we do a rebuild of the 
whole table and then call analyze() on the table.Presently for any optimize()
option (on table or partition) we display the following info to the user 

"Table does not support optimize, doing recreate + analyze instead".

FIX
---

It was decided for GA versions(5.1 and 5.5) whenever the user tries to 
optimize a partition(s) we will will display the following info the user

"Table does not support optimize on partitions.
All partitions will be rebuilt and analyzed."

Earlier partitions were not analyzed.Now all partitions  will be analyzed.  

If the user wants to optimize the whole table ,we will display the
previous info to the user. i.e

"Table does not support optimize, doing recreate + analyze instead"

For 5.6+ versions we will raise a new bug to support optimize() options
in innodb.


--BZR--
revision-id: aditya.a@oracle.com-20121106130503-9wse4v8c0teo619b
property-audit-revid: aditya.a@oracle.com-20121106130503-9g70e7g22342afdk
property-branch-nick: mysql-5.1
testament3-sha1: 3a5233b7688e79ee31ee3076bbb4e1643171e024
Bug#11751825 - OPTIMIZE PARTITION RECREATES FULL TABLE INSTEAD JUST PARTITION

PROBLEM 
-------

optimize on partiton will recreate the whole table 
instead of just partition.

ANALYSIS
--------

At present innodb doesn't support optimize option ,so we do a rebuild of the 
whole table and then call analyze() on the table.Presently for any optimize()
option (on table or partition) we display the following info to the user 

"Table does not support optimize, doing recreate + analyze instead".

FIX
---

It was decided for GA versions(5.1 and 5.5) whenever the user tries to 
optimize a partition(s) we will will display the following info the user

"Table does not support optimize on partitions.
All partitions will be rebuilt and analyzed."

Earlier partitions were not analyzed.Now all partitions  will be analyzed.  

If the user wants to optimize the whole table ,we will display the
previous info to the user. i.e

"Table does not support optimize, doing recreate + analyze instead"

For 5.6+ versions we will raise a new bug to support optimize() options
in innodb.


--BZR--
revision-id: aditya.a@oracle.com-20121106131422-3hqzd7xbqam4zcwz
property-audit-revid: aditya.a@oracle.com-20121106131422-j41zjiqr01mwj1jb
property-branch-nick: mysql-5.5
testament3-sha1: 291d9e47473cd813153f9f813831e8c26a807d43
Bug #11759445: CAN'T DELETE ROWS FROM MEMORY TABLE WITH HASH KEY.

Brief description: After insert some rows to MEMORY table with HASH key some 
rows can't be deleted in one step.    

Problem Analysis/solution: info->current_ptr will have the information about the
current hash pointer from where we can traverse to the list to get all the       
remaining tuples.
      
In hp_delete_key we are updating info->current_ptr with the last_pos based on       
the flag parameter(which is the keydef and last index are same). As part of the       
fix we are making it to zero only when the code flow reaches to the end of the       
function hp_delete_key() it means that the next record which has to get deleted       
will be at the starting of the list so, that in the next call to       
read record(heap_rnext()) will take line number 100 path instead of 102 path, 
please see the below code in file hp_rnext.c, function heap_rnext().
 99       else if (!info->current_ptr)              /* Deleted or first call */
100         pos= hp_search(info, keyinfo, info->lastkey, 0);
101       else  
102         pos= hp_search(info, keyinfo, info->lastkey, 1);

with that change the hp_search() will update the info->current_ptr with the 
record which needs to be deleted.
--BZR--
revision-id: venkata.sidagam@oracle.com-20121107033017-mevgrtbho5lpcnyt
property-audit-revid: venkata.sidagam@oracle.com-20121107033017-abb6zwpsr4ws5yo1
property-branch-nick: 5.1
property-file-info: ld7:file_id64:sp1f-hp_delete.c-19700101030959-q7d6q5ne5m2n4f7u4yelrklhkm2ksgun7:message88:In heap_delete_key() function we are making info->current_ptr to 0 if 
property-file-info: flag is enabled.
property-file-info: 4:path24:storage/heap/hp_delete.cee
testament3-sha1: 34fab45868a0d70770b48d12d119f82657525bd3
Bug #11759445: CAN'T DELETE ROWS FROM MEMORY TABLE WITH HASH KEY.

Merging from 5.1 to 5.5
--BZR--
revision-id: venkata.sidagam@oracle.com-20121107033333-8v5s39heveorhx60
property-audit-revid: venkata.sidagam@oracle.com-20121107033333-rlm9sstckr7m0h0z
property-branch-nick: 5.5
testament3-sha1: bcc93b9f3473431ec28f5bb9aa1a9e3199dacb5c


--BZR--
revision-id: mysql-builder@oracle.com-20121107131142-sq0x4w63mo0zhc1i
property-audit-revid: ashish.y.agarwal@oracle.com-20121107131142-e45bdevvymp6ctup
property-branch-nick: clone
testament3-sha1: 077fccf940051dde670fe317382a24ff5d13d273
Bug#14466617 - INVALID WRITES AND/OR CRASH WITH USER
               VARIABLES 

Analysis:
-------------
After executing the query, new value of the user defined
variables are set in the function "select_dumpvar::send_data".
"select_dumpvar::send_data" first calls function 
"Item_func_set_user_var::save_item_result()". This function
checks the nullness of the Item_field passed as parameter 
to it and saves it. The nullness of item is stored with 
arg[0]'s null_value flag. Then "select_dumpvar::send_data" calls
"Item_func_set_user_var::update()" which notices null 
result that was saved and calls "Item_func_set_user_var::
update_hash". But here null_value is not set and args[0]
is different from that given to function "Item_func_set_user_var::
set_item_result()". This causes "Item_func_set_user_var::
update_hash" function to believe that its getting non-null value.
"user_var_entry::length" set to 0 and hence "user_var_entry::value"
is made to point to extra_area allocated in "user_var_entry".
And "Item_func_set_user_var::update_hash" tries to write
at memory beyond extra_area for result type DECIMAL. Because of 
this invalid write issue is reported by Valgrind.

Before this bug was introduced, we avoided this problem by 
creating "Item_func_set_user_var" object with the same 
Item_field as arg[0] and as parameter to 
Item_func_set_user_var::save_item_result(). But now 
they are refering to different args[0]. Because of this
null_value flag set in parameter Item_field in function
"Item_func_set_user_var::save_item_result()" is not
reflected in "Item_func_set_user_var" object.

Fix:
------------
This issue is reported on versions 5.5.24. Issue does not exists
in 5.5.23, 5.1, 5.6 and trunk.

This issue was introduced by
revid:georgi.kodinov@oracle.com-20120309130449-82e3bs5v3et1x0ef (fix for
bug #12408412), which was pushed into 5.5 and later releases. This patch
has later been reversed in 5.6 and trunk by
revid:norvald.ryeng@oracle.com-20121010135242-xj34gg73h04hrmyh (fix for
bug #14664077). Backported this patch in 5.5 also to fix this issue.

--BZR--
revision-id: praveenkumar.hulakund@oracle.com-20121107133833-ncnfj64zgs4966b6
property-audit-revid: praveenkumar.hulakund@oracle.com-20121107133833-zb802d1un7p3e2lf
property-branch-nick: mysql_5_5_new
property-file-info: ld7:file_id65:sp1f-item_func.cc-19700101030959-3wmsx76yvc25sroqpfrx2n77kqdxxn3y7:message49:here unsigned value is converted to signed value.4:path16:sql/item_func.cced7:file_id64:sp1f-item_func.h-19700101030959-fbjcbwkg66qubbzptqwh5w5evhnpukze7:message141:last_insert_id() gives an auto_incremented value which can be
property-file-info: positive only,so defined it as a unsigned longlong sets the
property-file-info: unsigned_flag to 1.4:path15:sql/item_func.hee
testament3-sha1: 56aaf2b7906ac4ebdcec62f3696de9c2ece50eb6
Placement change:

Top level "SPECIFIC-ULN/" was inappropriate,
put the files to create RPMs for ULN into
"packaging/rpm-uln/".
--BZR--
revision-id: joerg.bruehe@oracle.com-20121107164502-7j6rpu3rmzed1rfp
property-audit-revid: joerg.bruehe@oracle.com-20121107164502-8vn3vqhhlkqw99yk
property-branch-nick: place-uln-5.5
testament3-sha1: c093862c374c13412d1e662ab98530029a919f53
Make RPMs for ULN build again.

A change to "vio/viosslfactories.c" in August, 2012,
broke a patch which is to be applied during the build
of ULN RPMs.
The patch file is
"packaging/rpm-uln/mysql-chain-certs.patch"

This change bypasses the problem by not trying to apply
the patch.

This is a regression and must be fixed, not bypassed.
--BZR--
revision-id: joerg.bruehe@oracle.com-20121107193254-v51thnf4wc4xmldo
property-audit-revid: joerg.bruehe@oracle.com-20121107193254-f7zodfhdlyxjkkkp
property-branch-nick: place-uln-5.5
testament3-sha1: 91335aa40243e54f2edde2a6dca036e5dd919ef0
Bug#11751825 - OPTIMIZE PARTITION RECREATES FULL TABLE INSTEAD JUST PARTITION

Follow up patch to address the pb2 failures.

--BZR--
revision-id: aditya.a@oracle.com-20121108084927-3mu2y69cahqiirra
property-audit-revid: aditya.a@oracle.com-20121108084927-h98q5g9zfhx08o3c
property-branch-nick: mysql-5.1
testament3-sha1: ae4afd7a138a27c17d177fc73e8d0b2fd559b574
Bug#11751825 - OPTIMIZE PARTITION RECREATES FULL TABLE INSTEAD JUST PARTITION

Follow up patch to address the pb2 failures.

--BZR--
revision-id: aditya.a@oracle.com-20121108085302-au4bkzr90cpwm7x1
property-audit-revid: aditya.a@oracle.com-20121108085302-jt8edqn272yvxwrk
property-branch-nick: mysql-5.5
testament3-sha1: 715bdb7169d0723bbb5ae4e3970e3f81d506bc47
Bug#14234028 - CRASH DURING SHUTDOWN WITH BACKGROUND PURGE THREAD
 
 Analysis
 --------- 
 
 my_stat() calls stat() and if the stat() call fails we try to set 
 the variable  my_errno which is actually a thread specific data .
 We try to get the  address of this thread specific data using
 my_pthread_getspecifc(),but for the purge thread we have not defined 
 any thread specific data so it returns null and when dereferencing 
 null we get a segmentation fault.
        init_available_charsets() seen in the core stack is invoked 
 through  pthread_once() .pthread_once is used for one time 
 initialization.Since free_charsets() is called before innodb plugin 
 shutdown ,purge thread calls init_avaliable_charsets() which leads 
 to the crash.

 Fix
 ---
 Call free_charsets() after the innodb plugin shutdown,since purge 
 threads are still using the charsets. 

--BZR--
revision-id: aditya.a@oracle.com-20121108094429-6bpsov4q5z1xze0q
property-audit-revid: aditya.a@oracle.com-20121108094429-z05sgn23xcat1nm9
property-branch-nick: mysql-5.1
testament3-sha1: 95e890e32a636af76b17fe9a48bb0c3b9a18cf80