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.

No commit message

      
Description: A very large database name causes buffer
             overflow in functions acl_get() and
             check_grant_db() in sql_acl.cc. It happens
             due to an unguarded string copy operation.
             This puts required sanity checks before
             copying db string to destination buffer.

After-push cleanup: removal of unneeded assertions.

Code in MDL subsystem assumes that identifiers of objects can't
be longer than NAME_LEN characters. This assumption was broken
when one tried to construct MDL_key based on table alias, which
can have arbitrary length. Since MDL_key's (and MDL locks) are
not really used for table aliases this patch changes code to
not initialize MDL_key object for table list element representing
aliases.

The patch "mysql-chain-certs.patch" needs to be adapted
to code changes in "vio/viosslfactories.c" which were
done in MySQL 5.5.

Top level "SPECIFIC-ULN/" was inappropriate,
put the files to create RPMs for ULN into
"packaging/rpm-uln/".

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.

Problem description:
mysql server crashes when we run repair table on currupted table.

Analysis:
The problem with this bug seem to be key_reflength out of bounds
(186 according to debugger). We read this value from meta-data
segment of .MYI file while doing mi_open().

If you look into _mi_kpointer() you can see that the upper limit
for key_reflength is 7.

Solution:
In mi_open() there is a line like:
  if (share->base.keystart > 65535 || share->base.rec_reflength > 8)
we should verify key_reflength here as well.

              DISABLE AND ENABLED DURING DDL OPERATION

PROBLEM: Same thread trying to acquire the same mutex
         second time leads to hang/server crash.
         While [un]installing audit_log plugin
         a thread acquires the LOCK_plugin mutex
         and after successful initialization tries
         to write in mysql.plugin table. It holds
         this mutex for a long time. If some how
         plugin table is corrupted then a write to 
         plugin table will throw an error, thread try
         to log this error in the audit_log plugin,
         doing so it tries to acquire the mutex
         again and results is server hang/crash.

SOLUTION: Releasing the LOCK_plugin mutex before
          writing in mysql.plugin table. We dont
          need to hold this mutex as thread already
          acquired a TL_WRITE lock on mysql.plugin
          table.

              TO MYISAM_SORT_BUFFER_SIZE
Null Merge from 5.1 to 5.5

              TO 'MYISAM_SORT_BUFFER_SIZE'
Merging from 5.1 to 5.5

              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.

              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.

merge from 5.1 into 5.5

               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. 

No commit message

No commit message

No commit message

No commit message

Part three:
Fix some search paths.

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.

Merge from mysql-5.1 into mysql-5.5.

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

Null merge from mysql-5.1 into mysql-5.5.

Merge bundle on mysql-5.5.

Merge bundle on mysql-5.1.

When a DML statement is issued, and if the index merge 
access method is chosen, then many rows from the
storage engine will be locked because of the way the
algorithm works.  Many rows will be locked, but they
will not be part of the final result set.

To reduce the excessive locking, the locks of unmatched
rows are released by this patch.  This patch will 
affect only transactions with isolation level
equal to or less stricter than READ COMMITTED. This is
because of the behaviour of ha_innobase::unlock_row().

rb://1296 approved by jorgen and olav.

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.

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.