MDEV-729 lp:998028 - Server crashes on normal shutdown in closefrm after executing a query from MyISAM table

don't write a key value into the record buffer - a key length can be larger then the record length.

MDEV-759 lp:998340 - Valgrind complains on simple selects containing expression DAY(FROM_UNIXTIME(-1))

check item->null_value before using the result of item->val_int()

This bug could result in returning 0 for the expressions of the form 
<aggregate_function>(distinct field) when the system variable  
max_heap_table_size was set to a small enough number.
It happened because the method Unique::walk() did not support
the case when more than one pass was needed to merge the trees
of distinct values saved in an external file.

Backported a fix in grant_lowercase.test from mariadb 5.5.

MDEV-4029 SELECT on information_schema using a subquery locks up the information_schema table due to incorrect mutexes handling
  
Early evaluation of subqueries in the WHERE conditions on I_S.*_STATUS tables,
otherwise the subquery on this same table will try to acquire LOCK_status twice.

taking a change done to main 5.1 by Dmitri Lenev.

This is the original comment:

> committer: Dmitry Lenev <Dmitry.Lenev@oracle.com>
> branch nick: mysql-5.1-15954896
> timestamp: Wed 2012-12-05 19:26:56 +0400
> message:
>   Bug #15954896 "SP, MULTI-TABLE DELETE AND LONG ALIAS".

  Using too long table aliases in stored routines might
  have caused server crashes.

  Code in sp_head::merge_table_list() which is responsible
  for collecting information about tables used in stored
  routine was not aware of the fact that table alias might
  have arbitrary length. I.e. it assumed that table alias
  can't be longer than NAME_LEN bytes and allocated buffer
  for a key identifying table accordingly.

  This patch fixes the issue by ensuring that we use
  dynamically allocated buffer for table key when table
  alias is too long. By default stack based buffer is used
  in which NAME_LEN bytes are reserved for table alias.

The failure is caused by failing stat() call . C Runtime function stat() uses old struct with 32bit st_size member,
and since Visual Studio 2010 , it returns an error on st_size overflow (i.e on files larger than 4GB)

Fix replaces stat() by my_stat(), the later is backed by 64bit-able stat64().

Fix some problems in the TC_LOG_MMAP commit processing, which could
lead to assertions in some cases.

Problems are mostly reproducible in MariaDB 10.0 with asynchroneous
commit checkpoints, but most of the problems were present in earlier
versions also.

followup fixes for MySQL Bug #13889741: HANDLE_FATAL_SIGNAL IN _DB_ENTER_ | HANDLE_FATAL_SIGNAL IN STRNLEN

Take into account that length of strings passed down to this function can be up to FN_REFLEN+1 bytes. including terminating zero.
The overwrite was caused by incomplete fix to MySQL Bug # 44834

add a test case for MySQL Bug #13889741: HANDLE_FATAL_SIGNAL IN _DB_ENTER_ | HANDLE_FATAL_SIGNAL IN STRNLEN

Add missing DBUG_RETURNs, otherwise the debug-stack gets messed up,
and _db_enter_ and _db_exit_ will access data outside the current stack frame.

mysql-test/r/partition.result:
  Added test case
mysql-test/t/partition.test:
  Added test case
sql/ha_partition.cc:
  Removed printing of not initialized variable
storage/maria/ha_maria.cc:
  Don't copy variables that are not initialized

storage/maria/ma_test2.c:
  Problem was that rnd() generated bigger value than allocated array

              TO 'MYISAM_SORT_BUFFER_SIZE'
Problem: 'myisam_sort_buffer_size' is a parameter used by 
mysqld program only whereas 'sort_buffer_size' is used by
mysqld and myisamchk programs. But the error message printed
when myisamchk program is run with insufficient buffer size 
is myisam_sort_buffer_size is too small which may mislead to the
server parameter myisam_sort_buffer_size.
SOLUTION: A parameter 'myisam_sort_buffer_size' is added as an
alias for 'sort_buffer_size' and the 'sort_buffer_size' parameter
is marked as deprecated. So myisamchk also has both the parameters
with the same role.

               main.mysqlbinlog_row_innodb are skipped by mtr

=== Problem ===

The following tests are wrongly placed in main suite and as a
result these are not run with proper binlog format combinations.
Some are always skipped by mtr.
1) mysqlbinlog_row_myisam
2) mysqlbinlog_row_innodb
3) mysqlbinlog_row.test
4) mysqlbinlog_row_trans.test
5) mysqlbinlog-cp932
6) mysqlbinlog2
7) mysqlbinlog_base64

=== Background ===

mtr runs the tests placed in main suite with binlog format=stmt.
Those that need to be tested against binlog format=row or mixed
or more than one binlog format and require only one mysql server
are placed in binlog suite. mtr runs tests in binlog suite with
all three binlog formats(stmt,row and mixed).

=== Fix ===


1) Moved the test listed in problem section above to binlog suite.
2) Added prefix "binlog_" to the name of each test case moved.
   Renamed the coresponding result files and option files accordingly. 


mysql-test/extra/binlog_tests/mysqlbinlog_row_engine.inc:
  include file for mysqlbinlog_row_myisam.test and 
  mysqlbinlog_row_myisam.test which are being moved to
  binlog suite.
mysql-test/suite/binlog/r/binlog_mysqlbinlog-cp932.result:
  result file for mysqlbinlog-cp932.test which is being moved to
  binlog suite.
mysql-test/suite/binlog/r/binlog_mysqlbinlog2.result:
  result file for mysqlbinlog2.test which is being moved to
  binlog suite.
mysql-test/suite/binlog/r/binlog_mysqlbinlog_base64.result:
  result file for mysqlbinlog_base64.test which is being moved to
  binlog suite.
mysql-test/suite/binlog/r/binlog_mysqlbinlog_row.result:
  result file for mysqlbinlog_row.test which is being moved to
  binlog suite.
mysql-test/suite/binlog/r/binlog_mysqlbinlog_row_innodb.result:
  result file for mysqlbinlog_row_innodb.test which is being moved to
  binlog suite.
mysql-test/suite/binlog/r/binlog_mysqlbinlog_row_myisam.result:
  result file for mysqlbinlog_row_myisam.test which is being moved to
  binlog suite.
mysql-test/suite/binlog/r/binlog_mysqlbinlog_row_trans.result:
  result file for mysqlbinlog_row_trans.test which is being moved to
  binlog suite.
mysql-test/suite/binlog/t/binlog_mysqlbinlog-cp932-master.opt:
  option file for mysqlbinlog-cp932.test which is being moved to
  binlog suite.
mysql-test/suite/binlog/t/binlog_mysqlbinlog-cp932.test:
  the test requires binlog format=stmt or mixed. Since, it was placed in
  main suite earlier, it was only run with binlog format=stmt, and hence
  this test was never run with binlog format=mixed.
mysql-test/suite/binlog/t/binlog_mysqlbinlog2.test:
  the test requires binlog format=stmt or mixed. Since, it was placed in
  main suite earlier, it was only run with binlog format=stmt, and hence
  this test was never run with binlog format=mixed.
mysql-test/suite/binlog/t/binlog_mysqlbinlog_base64.test:
  the test requires binlog format=row. Since, it was placed in main
  suite earlier, it was only run with binlog format=stmt, and hence
  this test was always skipped by mtr.
mysql-test/suite/binlog/t/binlog_mysqlbinlog_row.test:
  the test requires binlog format=row. Since, it was placed in main
  suite earlier, it was only run with binlog format=stmt, and hence
  this test was always skipped by mtr.
mysql-test/suite/binlog/t/binlog_mysqlbinlog_row_innodb.test:
  the test requires binlog format=row. Since, it was placed in main
  suite earlier, it was only run with binlog format=stmt, and hence
  this test was always skipped by mtr.
mysql-test/suite/binlog/t/binlog_mysqlbinlog_row_myisam.test:
  the test requires binlog format=row. Since, it was placed in main
  suite earlier, it was only run with binlog format=stmt, and hence
  this test was always skipped by mtr.
mysql-test/suite/binlog/t/binlog_mysqlbinlog_row_trans.test:
  the test requires binlog format=row. Since, it was placed in main
  suite earlier, it was only run with binlog format=stmt, and hence
  this test was always skipped by mtr.

No commit message

IN ALTER TABLE ... ADD UNIQUE KEY

A bogus debug assertion failure occurred when reporting a duplicate
key on a column prefix of a CHAR column.

This is a regression from Bug#14729221 IN-PLACE ALTER TABLE REPORTS ''
INSTEAD OF REAL DUPLICATE VALUE FOR PREFIX KEYS. The assertion is only
present when UNIV_DEBUG is defined (which it is in debug builds
starting from MySQL 5.5). It is a case of overasserting.

Fix approved by Inaam Rana on IM.

Moved explicit instantiation of available_buffer and valid_buffer_range 
template functions to sql/log_event.cc.

Merge bundle on mysql-5.1.

Problem:-
When we execute a query which has subquery with GROUP BY, ORDER BY and have a
BLOB column,results a memory leak.

Analysis:-
In case of subquery, which have GROUP BY on BLOB and a ORDER BY on other field
and BLOB is not a key. We allocate a tmp buffer to copy_field to take care of
BLOB value.This copy_field value can have copies of its in two join(objects),
so while freeing this copy_field we have to take care that it is
not deleted twice.
The double deletion of tmp_table_param.copy_field is handled by two patches.

One by Kostja :
revid:sp1r-konstantin@mysql.com-20050627101056-55153
Fix the broken test suite in -debug build.

and other by Oleksandr
revid:sp1r-bell@sanja.is.com.ua-20060118114857-19905
Excluded posibility of tmp_table_param.copy_field double deletion (BUG#14851).

both of this patches are commited in different branch and while
merging they both get placed,but there is no need for Kostja patch as Oleksandr
patch handle this.


sql/sql_select.cc:
  Bug13726751, tmp_join clean up is not necessary as later in the code we are taking care of cleaning up of tmp_join copy_field.

LEN <= SIZEOF(ULONGLONG)

This bug was caught in the WL#6255 ALTER TABLE...ADD COLUMN in MySQL
5.6, but there is a bug in all InnoDB versions that support
auto-increment columns.

row_search_autoinc_read_column(): When reading the maximum value of
the auto-increment column, and the column only contains NULL values,
return 0. This corresponds to the case when the table is empty in
row_search_max_autoinc().

rb:1415 approved by Sunny Bains

mysqld_safe script did not heed MySQL specific environment variable
$UMASK, leading to divergent behavior between mysqld and mysqld_safe.

Patch adds an approximation of mysqld's behavior to mysqld_safe,
within the bounds dictated by attempt to have mysqld_safe run on
even the most basic of shells (proper '70s sh, not just bash
with a fancy symlink).

Patch also adds approximation of said behavior to mysqld_multi
(in perl).

(backport)

rb://1334
approved by: Inaam Rana

mysqld_safe script did not heed MySQL specific environment variable
$UMASK, leading to divergent behavior between mysqld and mysqld_safe.

Patch adds an approximation of mysqld's behavior to mysqld_safe,
within the bounds dictated by attempt to have mysqld_safe run on
even the most basic of shells (proper '70s sh, not just bash
with a fancy symlink).

Patch also adds approximation of said behavior to mysqld_multi
(in perl).

Problem:-
using last_insert_id() on an auto_incremented bigint unsigned does
not work for values which are greater than max-bigint-signed.

Analysis:-
last_insert_id() returns the first auto_incremented value for a column
and an auto_incremented value can have only positive values.

In our code, when we are initializing a last_insert_id object, we are
taking it as a signed BIGINT, So when the auto_incremented value reaches
greater than max signed bigint, last_insert_id gives negative result.

Solution:
When we are fetching the value from last_insert_id, We are setting the 
unsigned_flag, so that it take only unsigned BIGINT value.

sql/item_func.cc:
  here unsigned value is converted to signed value.
sql/item_func.h:
  last_insert_id() gives an auto_incremented value which can be
  positive only,so defined it as a unsigned longlong sets the
  unsigned_flag to 1.