FOREVER MDL LOCK

Analysis:
----------
While granting MDL lock for the lock requests in wait queue,
first the lock is granted to the high priority lock types
and then to the low priority lock types.

MDL Priority Matrix,
  +-------------+----+---+---+---+----+-----+
  | Locks       |    |   |   |   |    |     |
  | has Priority|    |   |   |   |    |     |
  | over --->   |  S | SR| SW| SU| SNW| SNRW|   
  +-------------+----+---+---+---+----+-----+
  | X           |  + | + | + | + | +  | +   |
  +-------------|----|---|---|---|----|-----|
  | SNRW        |  - | + | + | - | -  | -   |
  +-------------|----|---|---|---|----|-----|
  | SNW         |  - | - | + | - | -  | -   |
  +-------------+----+---+---+---+----+-----+

Here '+' means, Lock priority is higher.
     '-' means, Has same priority

In the scenario where,
   *. Lock wait queue has requests of type S/SR/SW/SU.
   *. And locks of high priority X/SNRW/SNW are requested 
      continuously.

In this case, while granting lock, always first high priority 
lock requests(X/SNRW/SNW) are considered. Low priority 
locks(S/SR/SW/SU) will not get chance and they will 
wait forever.

In the scenario for which this bug is reported, application
executed many LOCK TABLES ... WRITE statements concurrently.
These statements request SNRW lock. Also there were some
connections trying to execute DML statements requesting SR
lock. Since SNRW lock request has higher priority (and as
they were too many waiting SNRW requests) lock is always 
granted to it. So, lock request SR will wait forever, resulting
in DML starvation.

How is this handled in 5.1?
---------------------------
Even in 5.1 we have low priority lock starvation issue.
But, in 5.1 thread locking, system variable 
"max_write_lock_count" can be configured to grant
some pending read lock requests. After 
"max_write_lock_count" of write lock grants all the low
priority locks are granted.

Why this issue is seen in 5.5/trunk?
---------------------------------
In 5.5/trunk MDL locking, "max_write_lock_count" system 
variable exists but not used in MDL, only thread lock uses
it. So no effect of "max_write_lock_count" in MDL locking.
This means that starvation of metadata locks is possible 
even if max_write_lock_count is used.

Looks like, customer was using "max_write_lock_count" in
5.1 and when upgraded to 5.5, starvation is seen because
of not having effect of "max_write_lock_count" in MDL.

Fix:
----------
As a fix, support for max_write_lock_count is added to MDL.
To maintain write lock counter per MDL_lock object, new
member "m_hog_lock_count" is added in MDL_lock.

And following logic is added to increment the counter in 
function reschedule_waiters, 
(reschedule_waiters function is called while thread is
 releasing the lock)
    - After granting lock request from the wait queue.
    -  Check if there are any S/SR/SU/SW exists in the wait queue
      - If yes then increment the "m_hog_lock_count"

And following logic is added in the same function to
handle pending S/SU/SR/SW locks
    
    - Before granting locks 
    - Check if max_write_lock_count <= m_hog_lock_count
    - If Yes, then try to grant S/SR/SW/SU locks. 
      (Since all of these has same priority, all locks are
       granted together. But some lock grant may fail because
       of grant incompatibility)
    - Reset m_hog_lock_count if there no low priority lock
      requests in wait queue. 
    - return

Note:
--------------------------
In the lock priority matrix explained above,
though X has priority over the SNW and SNRW. X locks is
taken mostly for RENAME, TRUNCATE, CREATE ... operations.
So lock type X may not be requested in loop continuously 
in real world applications, as compared to other lock 
request types. So, lock request of type SNW and SNRW are 
not starved. So, we can grant all S/SR/SU/SW in one shot,
without considering SNW & SNRW lock request starvation.

ALTER table operations take SU lock first and then 
upgrade to SNW if required. All S, SR, SW, SU have same
lock priority. So while granting SU, request of types
SR, SW, S are also granted in one shot. So, lock request 
of type SU->SNW in loop will not make other low priority 
lock request to starve.

But, when there is request for lock of type SNRW, lock
requests of lower priority types are not granted. And if 
SNRW is requested in loop continuously then all 
S, SR, SW, SU are starved.

This patch addresses the latter scenario.
When we have S/SR/SW/SU in wait queue and if 
there are
    - Continuous SNRW lock requests
    - OR one or more X and Continuous SNRW lock requests.
    - OR one SNW and Continuous SNRW lock requests.
    - OR one SNW, one or more X and continuous SNRW lock 
      requests.
in wait queue then, S/SR/SW/SU lock request are starved.

Backport the fix from 5.6 to 5.1
Base bug number : 11765562

Space available for merging was calculated incorrectly.

Null merge from 5.1 to 5.5

Fixed the missing of federated/include folder at the time 
of preparing package distribution, issue happens only in 5.1

               IS PLACE HOLDER AND USE SERVER-SIDE 

Analysis:
LIMIT always takes nonnegative integer constant values. 

http://dev.mysql.com/doc/refman/5.6/en/select.html

So parsing of value '5' for LIMIT in SELECT fails.

But, within prepared statement, LIMIT parameters can be
specified using '?' markers. Value for the parameter can
be supplied while executing the prepared statement.

Passing string values, float or double value for LIMIT
works well from CLI. Because, while setting the value
for the parameters from the variable list (added using
SET), if the value is for parameter LIMIT then its 
converted to integer value. 

But, when prepared statement is executed from the other
interfaces as J connectors, or C applications etc.
The value for the parameters are sent to the server
with execute command. Each item in log has value and
the data TYPE. So, While setting parameter value
from this log, value is set to all the parameters
with the same data type as passed.
But here logic to convert value to integer type
if its for LIMIT parameter is missing.
Because of this,string '5' is set to LIMIT.
And the same is logged into the binlog file too. 

Fix:
When executing prepared statement having parameter for
CLI it worked fine, as the value set for the parameter
is converted to integer. And this failed in other 
interfaces as J connector,C Applications etc as this 
conversion is missing.

So, as a fix added check while setting value for the
parameters. If the parameter is for LIMIT value then
its converted to integer value.

                  
Merged pb2 test failure fix from mysql-5.1 to mysql-5.5

Fix for pb2 test failure.

             WORK + SAVES ROOT PASSWORD TO DISK!

The secure installation scripts connect to the
server by storing the password in a temporary
option file. Now, if the script gets killed or
fails for some reason, the removal of the option
file may not take place.

This patch introduces following enhancements :
* (.sh) Made sure that cleanup happens at every
  call to 'exit 1'. This is performed implicitly
  by END{} in pl.in.
* (.pl.in) Added a warning in case unlink fails
  to delete the option/query files.
* (.sh/.pl.in) Added more signals to the signal
  handler list. SIG# 1, 3, 6, 15

      
Merged from mysql-5.1 to mysql-5.5

Problem description:
Table 't' created with two colums having compound index on both the 
columns under innodb/myisam engine at remote machine. In the local 
machine same table is created undet the federated engine.
A select having where clause with along 'AND' operation gives wrong 
results on local machine.

Analysis: 
The given query at federated engine is wrongly transformed by 
federated::create_where_from_key() function and the same was sent to 
the remote machine. Hence the local machine is showing wrong results.

Given query "select c1 from t where c1 <= 2 and c2 = 1;"
Query transformed, after ha_federated::create_where_from_key() function is:
SELECT `c1`, `c2` FROM `t` WHERE  (`c1` IS NOT NULL ) AND 
( (`c1` >= 2)  AND  (`c2` <= 1) ) and the same sent to real_query().
In the above the '<=' and '=' conditions were transformed to '>=' and 
'<=' respectively.

ha_federated::create_where_from_key() function behaving as below:
The key_range is having both the start_key and end_key. The start_key 
is used to get "(`c1` IS NOT NULL )" part of the where clause, this 
transformation is correct. The end_key is used to get "( (`c1` >= 2) 
AND  (`c2` <= 1) )", which is wrong, here the given conditions('<=' and '=') 
are changed as wrong conditions('>=' and '<=').
The end_key is having {key = 0x39fa6d0 "", length = 10, keypart_map = 3, 
flag = HA_READ_AFTER_KEY}

The store_length is having value '5'. Based on store_length and length 
values the condition values is applied in HA_READ_AFTER_KEY switch case.
The switch case 'HA_READ_AFTER_KEY' is applicable to only the last part of 
the end_key and for previous parts it is going to 'HA_READ_KEY_OR_NEXT' case, 
here the '>=' is getting added as a condition instead of '<='.

Fix:
Updated the 'if' condition in 'HA_READ_AFTER_KEY' case to affect for all 
parts of the end_key. i.e 'i > 0' will used for end_key, Hence added it in 
the if condition.

PROBLEM: 
mysql provides a feature where in a session which is 
idle for a period specified by the wait_timeout variable
(whose value is in seconds), the session is closed
This feature is not present when we use thread pool.
FIX:
This patch implements the interface functions which is 
required to implement the wait_timeout functionality
in the thread pool plugin.

"warning: integer constant is too large for 'long' type"

Backporting the WL#5716, "Information schema table for InnoDB 
buffer pool information". Backporting revisions 2876.244.113, 
2876.244.102 from mysql-trunk.

rb://1175 approved by Jimmy Yang. 

Backporting the WL#5716, "Information schema table for InnoDB
buffer pool information". Backporting revisions 2876.244.113,
2876.244.102 from mysql-trunk.

rb://1177 approved by Jimmy Yang. 

Problem: Valgrind reports errors when an invalid certificate is used on the
         client.

Solution: Updated yaSSL to version 2.2.2.

'MAX_BINLOG_CACHE_SIZE' ERROR
      
Problem:
=======
MySQL returns following error in win64.
"ERROR 1197 (HY000): Multi-statement transaction required more than
'max_binlog_cache_size' bytes of storage; increase this mysqld variable
and try again" when user tries to load >4G file even if
max_binlog_cache_size set to maximum value. On Linux everything
works fine.
      
Analysis:
========
The `max_binlog_cache_size' variable is of type `ulonglong'.  This
value is set to `ULONGLONG_MAX' at the time of server start up. The
above value is stored in an intermediate variable named
`saved_max_binlog_cache_size' which is of type `ulong'. In visual
c++ complier the `ulong' type is of 4bytes in size and hence the value
is getting truncated to '4GB' and the cache is not able to grow beyond
4GB size. The same limitation is observed with 
"max_binlog_stmt_cache_size" as well. Similar fix has been applied.
      
Fix:
===
As part of fix the type "ulong" is replaced with "my_off_t" which is of
type "ulonglong". 

Add a macro "runselftest" to the spec file for RPM builds.

If its value is 1 (the default), the test suite will be run during
the RPM build.
To prevent that, add this to the rpmbuild command line:
    --define "runselftest 0"
Failures of the test suite will NOT make the RPM build fail!

while the copyright notice still mentioned 2003.

ISSUE: Incorrect key file. Key file is corrupted,
       Reading incorrect key information (keyseg)
       from index file. Key definition in .MYI
       and .FRM file differs. Starting pointer
       to read the keyseg information is changed
       to a value greater than the pack_reclength.
       Memcpy tries to read keyseg information from
       unallocated memory which causes the crash.

SOLUTION: One more check added to compare the
          the key definition in .MYI and .FRM
          file. If the definition differ, server
          produces an error.

No commit message

No commit message

  Added new minimal client using same framework
  Added internal test using it
  Small changes to top level make/configure/cmake to have it built

Merged from mysql-5.1 to mysql-5.5

Problem description:
Giving "help 'contents'" in the mysql client as a first statement
gives error

Analysis:
In com_server_help() function the "server_cmd" variable was
initialised with buffer->ptr(). And the "server_cmd" variable is not
updated since we are passing "'contents'"(with single quote) so the
buffer->ptr() consists of the previous buffer values and it was sent
to the mysql_real_query() hence we are getting error.

Fix:
We are not initialising the "server_cmd" variable and we are updating
the variable with "server_cmd= cmd_buf" in any of the case i.e with
single quote or without single quote for the contents.
As part of error message improvement, added new error message in case
of "help 'contents'".