IPV4/IPV6 ENABLED

Analysis:
----------------------
The problem was that if a hostname resolves to more than one IP-address,
the server (5.5) does not start due to an error. In 5.1 the server used to
take some IP-address and start.

It's a regression and should be fixed.

5.5 supports IPv6, while 5.1 does not. However, that should not 
prevent the server from start -- if a hostname has both IPv4 and IPv6 addresses,
the server should choose some IPv4-address and start.

It's been decided to prefer IPv4-address to be backward compatible with 5.1.

Another problem was that the 5.6 server did not report proper error message
when the specified hostname could not be resolved. So, the code has been 
changed to report proper error message.

Testing
================================
5.5
=============================
invalid hostname (localhos):
  => Following error message reported.
     120308 15:52:09 [ERROR] Can't start server: cannot resolve hostname!
     120308 15:52:09 [ERROR] Aborting

invalid ip_address:
  => Following error message reported.
      120308 15:56:06 [Note] Server hostname (bind-address): '123.123.123.123'; port: 3306
      120308 15:56:06 [Note]   - '123.123.123.123' resolves to '123.123.123.123';
      120308 15:56:06 [Note] Server socket created on IP: '123.123.123.123'.
      120308 15:56:06 [ERROR] Can't start server: Bind on TCP/IP port: Cannot assign requested address

Only ipv4 host configured:
  => Following message logged 
    120308 16:02:50 [Note] Server hostname (bind-address): 'localhost'; port: 3306
    120308 16:02:50 [Note]   - 'localhost' resolves to '127.0.0.1';
    120308 16:02:50 [Note] Server socket created on IP: '127.0.0.1'

Only ipv6 host configured:    
  => Following message logged 
    120308 16:04:03 [Note] Server hostname (bind-address): 'localhost'; port: 3306
    120308 16:04:03 [Note]   - 'localhost' resolves to '::1';
    120308 16:04:03 [Note] Server socket created on IP: '::1'.

ipv4 and ipv6 host configured:
  => Following message logged
    120308 16:05:02 [Note] Server hostname (bind-address): 'localhost'; port: 3306
    120308 16:05:02 [Note]   - 'localhost' resolves to '::1';
    120308 16:05:02 [Note]   - 'localhost' resolves to '127.0.0.1';
    120308 16:05:02 [Note] Server socket created on IP: '127.0.0.1'.
  => Non localhost address  
    120308 16:08:20 [Note] Server hostname (bind-address): 'mysql_addr'; port: 3306
    120308 16:08:20 [Note]   - 'mysql_addr' resolves to '10.178.58.216';
    120308 16:08:20 [Note]   - 'mysql_addr' resolves to 'fe80::120b:a9ff:fe69:59ec';
    120308 16:08:20 [Note] Server socket created on IP: '10.178.58.216'.

More than one entry for ipv4 and ipv6 address:
  => Following message logged
    120308 16:06:19 [Note] Server hostname (bind-address): 'localhost'; port: 3306
    120308 16:06:19 [Note]   - 'localhost' resolves to '::1';
    120308 16:06:19 [Note]   - 'localhost' resolves to '::1';
    120308 16:06:19 [Note]   - 'localhost' resolves to '127.0.0.1';
    120308 16:06:19 [Note]   - 'localhost' resolves to '127.0.0.1';
    120308 16:06:19 [Note] Server socket created on IP: '127.0.0.1'.

rev_id: inaam.rana@oracle.com-20120326134501-23554a8vhjg0wqbm

      
 Description: When the table has more than one unique or primary key, 
 INSERT... ON DUP KEY UPDATE statement is sensitive to the order in which
 the storage engines checks the keys. Depending on this order, the storage
 engine may determine different rows to mysql, and hence mysql can update
 different rows on master and slave.
      
 Solution: We mark INSERT...ON DUP KEY UPDATE on a table with more than on unique
 key as unsafe therefore the event will be logged in row format if it is available
 (ROW/MIXED). If only STATEMENT format is available, a warning will be thrown. 

Background:

  - as described in MySQL Internals Prepared Stored
    (http://forge.mysql.com/wiki/MySQL_Internals_Prepared_Stored),
    the Optimizer sometimes does destructive changes to the parsed
    LEX-object (Item-tree), which makes it impossible to re-use
    that tree for PS/SP re-execution.

  - in order to be able to re-use the Item-tree, the destructive
    changes are remembered and rolled back after the statement execution.

The problem, discovered by this bug, was that the objects representing
GROUP-BY clause did not restored after query execution. So, the GROUP-BY
part of the statement could not be properly re-initialized for re-execution
after destructive changes.

Those objects do not take part in the Item-tree, so they can not be saved
using the approach for Item-tree.

The fix is as follows:

  - introduce a new array in st_select_lex to store the original
    ORDER pointers, representing the GROUP-BY clause;

  - Initialize this array in fix_prepare_information().

  - restore the list of GROUP-BY items in reinit_stmt_before_use().

        
Fix the calculation of the next autoinc value when offset > 1. Some of the
results have changed due to the changes in the allocation calculation. The
new calculation will result in slightly bigger gaps for bulk inserts.
  
rb://866 Approved by Jimmy Yang.
Backported from mysql-trunk (5.6)

LOCK_THREAD_COUNT

When using the performance schema file io instrumentation in MySQL 5.5,
a thread would loop forever inside lf_pinbox_put_pins, when disconnecting.
It would also hold LOCK_thread_count while doing so, effectively killing the
server.

The root cause of the loop in lf_pinbox_put_pins() is a leak of LF_PINS,
when used with the filename_hash LF_HASH table in the performance schema.

This fix contains the following changes:

1)
Added the missing call to lf_hash_search_unpin(), to prevent the leak.

2)
In mysys/lf_alloc-pin.c, there was some extra debugging code
(MY_LF_EXTRA_DEBUG) written to detect precisely this kind of issues,
but it was never used.
Replaced MY_LF_EXTRA_DEBUG with DBUG_OFF, so that leaks similar to this one
can be always detected in regular debug builds.

3)
Backported the fix for the following bug, from 5.6 to 5.5:
Bug#13417446 - 63339: INCORRECT FILE PATH IN PEFORMANCE_SCHEMA ON WINDOWS

Analysis:
-------------------------------
According to the Manual
(http://dev.mysql.com/doc/refman/5.1/en/identifier-case-sensitivity.html):
"Column, index, stored routine, and event names are not case sensitive on any
platform, nor are column aliases."

In other words, 'lower_case_table_names' does not affect the behaviour of 
those identifiers.

On the other hand, trigger names are case sensitive on some platforms,
and case insensitive on others. 'lower_case_table_names' does not affect
the behaviour of trigger names either.

The bug was that SHOW statements did case sensitive comparison
for stored procedure / stored function / event names.

Fix:
Modified the code so that comparison in case insensitive for routines 
and events for "SHOW" operation.

As part of this commit, only fixing the test failures due to the actual code fix.

Change the type of purge_sys_t::n_pages_handled and purge_sys_t::handle_limit
to ulonglong from ulint. On a 32 bit system doing ~700 deletes per second the
counters can overflow in ~3.5 months, if they are 32 bit.

Approved by Jimmy Yang over IM.

Analysis:
-------------------------------
According to the Manual
(http://dev.mysql.com/doc/refman/5.1/en/identifier-case-sensitivity.html):
"Column, index, stored routine, and event names are not case sensitive on any
platform, nor are column aliases."

In other words, 'lower_case_table_names' does not affect the behaviour of 
those identifiers.

On the other hand, trigger names are case sensitive on some platforms,
and case insensitive on others. 'lower_case_table_names' does not affect
the behaviour of trigger names either.

The bug was that SHOW statements did case sensitive comparison
for stored procedure / stored function / event names.

Fix:
Modified the code so that comparison in case insensitive for routines 
and events for "SHOW" operation.

rb://942
approved by: Marko Makela

We don't need to scan LRU for dropping AHI entries when DROPing a table.
AHI entries are already removed when we free up extents for the btree.

Manually resolved conflicts in ".bzr-mysql/default.conf" (tree name)
and in "storage/innodb_plugin" (does not belong into 5.5).

solve a conflict in ".bzr-mysql/default.conf".

to mysql-5.5

rb://979 approved by Marko

conflict in "sql/filesort.cc" solved manually.

Problem:

Field_set::val_str in case of an empty SET value
returned a String with str_length==0 and Ptr==0,
which is not expected by some pieces of the code.

Fix:
      
Returning an empty string with str_length==0 and Ptr=="",
like Field_enum does.

  Doing this for Sayantan whose VPN is not working ATM

The test case must insert all the records using a single transaction. Otherwise the test 
case takes more than 15 minutes and will time out in pb2 and mtr.  

FROM BUFFER POOL

rb://975
approved by: Marko Makela

There is a race in lock_validate() where we try to access a page
without ensuring that the tablespace stays valid during the operation
i.e.: it is not deleted. This patch tries to fix that by using an
existing flag (the flag is renamed to make it's name more generic
in line with it's new use).

rb://976
approved by: Marko Makela

Add an assertion to ensure that string overflow is not happening.
Pointed by Coverity analysis.

IN OS_THREAD_EQ

rb://977
approved by: Marko Makela

rw_lock::writer_thread field contains the thread id of current x-holder
or wait-x thread. This field is un-initialized at lock creation and is
written to for the first time when an attempt is made to x-lock.

Current code considers ::writer_thread as valid memory region only when
the lock is held in x-mode (or there is an x-waiter). This is an
overkill and it generates valgrind warnings.

The fix is to consider ::writer_thread as valid memory region once it
has been written to.

Reasoning:
==========
The ::writer_thread can be safely considered valid because:

* We only ever do comparison with current calling threads id.
* We only ever do comparison when ::recursive flag is set
* We always unset ::recursive flag in x-unlock
* Same thread cannot be unlocking and attempting to lock at the same
time
* thread_id recycling is not an issue because before an id is recycled
the thread must leave innodb meaning it must release all locks meaning
it must unset ::recursive flag.

Pre-requisite patch.
Add end-of-file marker to 5.5 version of errmsg-utf8.txt.

AND SAVEPOINT.
      
The bug was introduced by the patch for bug#11766752. This patch sets too
strong condition on XA state for SAVEPOINT statement that disallows its
execution during XA transaction. But since the statement SAVEPOINT doesn't
imply implicit commit we can allow its handling during XA transaction.

The patch explicitly check for transaction state against states XA_NOTR
and XA_ACTIVE for which the handling of statement SAVEPOINT for XA
transaction is allowed.