into  mysql.com:/Users/kent/mysql/bk/bug17194/my51-bug17194

  Added ndb_error_reporter to the RPM install (bug#20426)

into  mysql.com:/Users/kent/mysql/bk/bug17194/my50-bug17194

  Added ndb_size.{pl,tmpl} to the RPM install (bug#20426)

into  moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.1-runtine-merge

into  moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.1-merge

into  moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.1-merge

into  janus.mylan:/usr/home/serg/Abk/m51

how did it get in?!? (it's only in local csets so no other tree is affected)

into janus.mylan:/usr/home/serg/Abk/m51

into  moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.1-merge

  After merge fix

into  lmy004.:/work/mysql-5.1-runtime

    
create function func() returns char(10) binary ...
is no more possible. This will be reenabled when 
bug 2676 "DECLARE can't have COLLATE clause in stored procedure"
is fixed.

Fix after 2nd review

into  moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.1-rt-merge

into  moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.1-merge

into  sunlight.local:/local_work/leak_fix-5.1-mysql

(this is not a fix to the bug, but simply to disable the test in 
order to push a 5.0 to 5.1 merge)

This merge contains:

Push by holyfoot@production.mysql.com on Tue Jul 25 13:41:40 2006:

bk clone -l -r'holyfoot/hf@mysql.com/deer.(none)|ChangeSet|20060725085017|41021' mysql-5.0 tmp_merge

  Correct memory leak fix

into  govinda.patg.net:/home/patg/mysql-build/mysql-5.1-5.0-merge2

Push by holyfoot@production.mysql.com on Tue Jul 25 13:41:40 2006:

bk clone -l -r'holyfoot/hf@mysql.com/deer.(none)|ChangeSet|20060725085017|41021' mysql-5.0 tmp_merge

we didn't check for NULL value of the
lex_create_info->db_type pointer.
The pointer is NULL in the case, when the engine name is
unknown to the server. This happens with NDB on Windows.

The following procedure was not possible if max_sp_recursion_depth is 0
create procedure show_proc() show create procedure show_proc;

Actually there is no recursive call but the limit is checked.

Solved by temporarily increasing the thread's limit just before the fetch from cache
and decreasing after that.

into  mysql.com:/home/cps/mysql/devel/5.1-curs-bug

into  maint1.mysql.com:/data/localhome/tsmith/bk/mrg51-c

into  neptunus.(none):/home/msvensson/mysql/mysql-5.1-new-maint

into  rama.(none):/home/jimw/my/mysql-5.1-clean

Use "--source" command instead of "source", makes mysql-test-run.pl dtecte this as test case that need binlog format row.

into  maint1.mysql.com:/data/localhome/tsmith/bk/mrg51-c

                gets deadlocked when dropping w/ log on"

Log tables rely on concurrent insert machinery to add data.
This means that log tables are always opened and locked by
special (artificial) logger threads. Because of this, the thread
which tries to drop a log table starts to wait for the table
to be unlocked. Which will happen only if the log table is disabled.
Alike situation happens if one tries to alter a log table.
However in addition to the problem above, alter table calls
check_if_locking_is_allowed() routine for the engine. The
routine does not allow alter for the log tables. So, alter
doesn't start waiting forever for logs to be disabled, but 
returns with an error.
Another problem is that not all engines could be used for
the log tables. That's because they need concurrent insert.

In this patch we:
(1) Explicitly disallow to drop/alter a log table if it
    is currently used by the logger.
(2) Update MyISAM to support log tables
(3) Allow to drop log tables/alter log tables if log is
    disabled
At the same time we (4) Disallow to alter log tables to
unsupported engine (after this patch CSV and MyISAM are 
alowed)
Recommit with review fixes.

into  neptunus.(none):/home/msvensson/mysql/mysql-5.1-new-maint

Due to incorrect handling of FLUSH TABLES, log tables were marked for flush,
but not reopened. Later we started to wait for the log table to be closed
(disabled) after the flush. And as nobody disabled logs in concurrent treads,
the command lasted forever.
After internal consultations it was decided to skip logs during FLUSH TABLES.
The reasoning is that logging is done in the "log device", whatever it is
which is always active and controlled by FLUSH LOGS. So, to flush logs
one should use FLUSH LOGS, and not FLUSH TABLES.

into  maint1.mysql.com:/data/localhome/tsmith/bk/mrg51-c

into  maint1.mysql.com:/data/localhome/tsmith/bk/mrg51-b