INSERT WITH SAME VALUES

Problem:

When a transaction is in READ COMMITTED isolation level, gap locks are still
taken in the secondary index, when row is inserted.  This happens when the
secondary index is scanned for duplicate.  

The function row_ins_scan_sec_index_for_duplicate() always calls the 
function row_ins_set_shared_rec_lock() with LOCK_ORDINARY irrespective of
the transaction isolation level.

Solution:

The function row_ins_scan_sec_index_for_duplicate() calls the 
function row_ins_set_shared_rec_lock() with LOCK_ORDINARY or 
LOCK_REC_NOT_GAP based on the transaction isolation level.

rb://2035 approved by Krunal and Marko

Approved by: Marko Makela (patch in bug report)

Reduce the number of debug buf_validate() calls

Fixing post push issue
Simulator name used needs to be changed to make it
work properly.

Analysis: 
Debug control list addition (ListAddDel function
dbug.c file) code was written in such a way that
if new element is subset of already existing element,
then the new element is not added.
i.e., set @@global.debug = '+d,abcd', is existing in
the list then you cannot add "a" or "ab" or "abc"
in the list.

              PROBLEM AFTER MYSQL_HA_FIND

This problem occured if a prepared statement tried to create a table
for which there already existed a view with the same name while a
SQL handler was opened.

Before DDL statements are executed, mysql_ha_rm_tables() is called
to remove any matching tables from the internal list of opened SQL
handler tables. This match was done on TABLE_LIST::db and 
TABLE_LIST::table_name. This is problematic for views (which use
TABLE_LIST::view_db and TABLE_LIST::view_name) and anonymous
derived tables.

This patch fixes the problem by skipping TABLE_LISTs representing
anonymous derived tables and using get_db_name()/get_table_name()
which handles views when looking for SQL handler tables to remove.

Before this fix, the command
  SHOW ENGINE PERFORMANCE_SCHEMA STATUS
could report wrong amount of memory allocated,
when the amount of memory used exceeds 4GB.

The problem is that size computations are not done using size_t,
so that overflows do occur, truncating the results.

This fix compute memory sizes properly with size_t.

Tested manually.

No test script provided, as the script would need to allocate too much 
memory for the test.

No commit message

No commit message

No commit message

IN IN-CLAUSE USING MYISAM OR MEMORY ENGINE

Backport from 5.6. Original message:

The coincidences caused a data loss:
* The query has IN subqueries nested twice,
* the WHERE clause of the inner subquery refers to the
  outer field, and the whole WHERE clause returns FALSE,
* the inner subquery has a LEFT JOIN that joins a single
  row with a row of NULLs; one of that NULL columns
  represents the select list of the subquery.

Normally, that inner subquery should return empty record set.
However, in our case:
* the Item_is_not_null_test item goes constant, since
  its underlying field is NULL (because of LEFT JOIN ... ON 
  FALSE of const table row with a row of nulls);
* we evaluate Item_is_not_null_test::val_int() as a part
  of fake HAVING expression of the transformed subquery;
* as far as the underlying field is NULL, we optimize
  out the whole fake HAVING expression as FALSE as well
  as a whole subquery with a zero result:
  Impossible HAVING noticed after reading const tables";
* thus, the optimizer ignores the presence of the WHERE
  clause (the WHERE expression is FALSE in our case, so
  the subquery should return empty set);
* however, during the evaluation of the 
  Item_is_not_null_test::val_int() in the optimizer,
  it marked its "owner" with the "was_null" flag -- that
  forced the subquery to return UNKNOWN instead of empty
  set.
That caused a wrong result.


The problem is a regression of the small cleanup in
the fix for the bug11827369 (the Item_is_not_null_test part)
that conflicts with optimizations in the fix for the bug11752543.
Before that regression the Item_is_not_null_test items
never were constants.

The fix is the rollback of Item_is_not_null_test parts
of the bug11827369 fix.

This is a deadlock that will also be fixed in the server by
Bug #11844915 - HANG IN THDVAR MUTEX ACQUISITION.
So this is a simple alternate method of fixing the same problem,
but from within InnoDB.

The simple change is to make rename table start a transaction
before locking dict_sys->mutex since thd_supports_xa() can call
THDVAR which can lock a mutex, LOCK_global_system_variables, that
is used in the server by many other activities.  At least one of
those, sys_var::update(), can call back into InnoDB and try to
lock dict_sys->mutex while holding LOCK_global_system_variables.

The other bug fix for 11844915 eliminates the use of
LOCK_global_system_variables for calls to THDVAR.

Approved by marko in http://rb.no.oracle.com/rb/r/2000/

page_zip_compress_node_ptrs(): Do not attempt to invoke deflate() with
c_stream->avail_in, because it will result in Z_BUF_ERROR (and
page_zip_compress() failure and unnecessary further splits of the node
pointer page). A node pointer record can have empty payload, provided
that all key fields are empty.

Approved by Jimmy Yang

              GRANT STATEMENT

Description: Merge from 5.1.

              GRANT STATEMENT

Description: A missing length check causes problem while
             copying source to destination when
             lower_case_table_names is set to a value
             other than 0. This patch fixes the issue
             by ensuring that requried bound check is
             performed.

1.  remove dummy.bak
2.  create a db.opt file containing two lines:

---
default-character-set=latin1
default-collation=latin1_swedish_ci

ANALYSIS
--------
 
When we open the view using open_new_frm() ,it doesnt set the
table-list->table variable and any access to table_list->table 
will cause a crash.
 
FIX
---
 
Added a check during execution of the alter partition to return 
error if table is view.

[http://rb.no.oracle.com/rb/r/2001/  Approved by Mattias J ]

                                                TO EXPECT FILE

No commit message

Problem:

When a system variable is being set to the DEFAULT value, the server
segfaults if there is no 'default' defined for that system variable.
For example, for the following statements server segfaults.

set session rand_seed1=DEFAULT;
set session rand_seed2=DEFAULT;

Analysis:

The class sys_var represents one system variable.  The class set_var represents
one system variable that is to be updated.   The class set_var contains two 
pieces of information, the system variable to object (set_var::var) member
and the value to be updated (set_var::value).

When the given value is 'default', the set_var::value will be NULL.

To update a system variable the member set_var::update() will be called, 
which in turn will call sys_var::update() or sys_var::set_default() depending
on whether a value has been provided or not.  

If the sys_var::set_default() is called, then the default value is obtained
either from the session scope or the global scope.  This default value is
stored in a local temporary set_var object and then passed on to the 
sys_var::update() call.  A local temporary set_var object is needed because
sys_var::set_default() does not take set_var as an argument.

In the given scenario, the set_var::update() called sys_var::set_default().
And this sys_var::set_default() obtains the default value and then calls
sys_var::update().  To pass this value to sys_var::update() a local set_var
object is being created.   While creating this local set_var object, its member
set_var::var was incorrectly left as 0.  

Solution:

Instead of creating a local set_var object, the sys_var::set_default() can take
the set_var object as an argument just like sys_var::update().

rb://1996 approved by Nirbhay and Ramil.

No commit message

No commit message

Sleep 1sec before remove_file to solve windows pb2 issues. We hope that
after sleep, the access to the file will not be denied.

Problem:

When the VALUES() function is inappropriately used in the SET stmt the server
exits.  

set port = values(v);

This happens because the values(v) will be parsed as an Item_insert_value by
the parser.  Both Item_field and Item_insert_value return the type as
FIELD_ITEM.  But for Item_insert_value the field_name member is NULL.  In
set_var constructor, when the type of the item is FIELD_ITEM we try to access
the non-existent field_name. 

The class hierarchy is as follows:
Item -> Item_ident -> Item_field -> Item_insert_value

The Item_ident::field_name is NULL for Item_insert_value.  

Solution:

In the parsing stage, in the set_var constructor if the item type is
FIELD_ITEM and if the field_name is non-existent, then it is probably
the Item_insert_value.  So leave it as it is for later evaluation.

rb://2004 approved by Roy and Norvald.

Cross-upgrades between GPL and commercial versions should be allowed by
the MSI package even when both packages are the same version.

Fixed by allowing upgrades to the same numeric version.

Add check for compressBound() and deflateBound()
Keep existing functionality: fallback to bundled zlib if functions not found.

move_file fails randomly on windows if the destination file exists.
Using remove_file before move_file mtr test command.

The random failure will be fixed by Bug#16263506 and this patch

Approved by Marko. rb#1988

HOST HAS '_' IN THE HOSTNAME

Problem:
=======
'_' and '%' are treated as a wildcards by the ACL code and
this is documented in the manual. The problem with
mysql_install_db is that it does not take this into account
when creating the initial GRANT tables:

--- cut ---
REPLACE INTO tmp_user SELECT @current_hostname,'root','','Y',
'Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y',
'Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','','','','',
0,0,0,0 FROM dual WHERE LOWER( @current_hostname) != 'localhost';
--- cut ---

If @current_hostname contains any wildcard characters, then 
a wildcard entry will be defined for the 'root' user, 
which is a flaw.

Analysis:
========
As per the bug description when we have a hostname with a
wildcard character in it, it allows clients from several other
hosts with similar name pattern to connect to the server as root.
For example, if the hostname is like 'host_.com' then the same
name is logged in mysql.user table. This allows 'root' users
from other hosts like 'host1.com', 'host2.com' ... to connect
to the server as root user.

While creating the intial GRANT tables we do not have a check
for wildcard characters in hostname.

Fix:
===
As part of fix escape character "\" is added before wildcard
character to make it a plain character, so that the one and
only host with the exact name will be able to connect to the
server.