into  bodhi.local:/opt/local/work/mysql-5.0-runtime-merge

into  lmy002.wdf.sap.corp:/home/georg/work/mysql/prod/mysql-5.0

  Delete: mysql-test/t/sp.test.orig

Fixes:
- bug #19834: Using cursors when running in READ-COMMITTED can cause InnoDB to crash
- bug #21112: InnoDB slow with > 100,000 .ibd files
- bug #21113: Duplicate printout in SHOW INNODB STATUS

into  mysql.com:/users/lthalmann/bk/MERGE/mysql-5.0-merge

into  mysql.com:/users/lthalmann/bk/MERGE/mysql-5.0-merge

into  mysql.com:/users/lthalmann/bk/MERGE/mysql-5.0-merge

into  mysql.com:/users/lthalmann/bk/MERGE/mysql-4.1-merge

into  weblab.(none):/home/marcsql/TREE/mysql-5.0-21269

The problem was that the grammar allows to create a function with an optional
definer clause, and define it as a UDF with the SONAME keyword.
Such combination should be reported as an error.

The solution is to not change the grammar itself, and to introduce a
specific check in the yacc actions in 'create_function_tail' for UDF,
that now reports ER_WRONG_USAGE when using both DEFINER and SONAME.

into  mysql.com:/Users/kent/mysql/bk/mysql-5.0

into  mysql.com:/Users/kent/mysql/bk/mysql-4.1

  Corrected typo

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

  Converted "udf_example.cc" to C, avoids C++ runtime lib dependency (bug#21336)

into  mysql.com:/Users/kent/mysql/bk/mysql-4.1

  Man page for mysqld command move to section 8 (bug#21220)

  Man page for "mysqld" command move to section 8 (bug#21220)

  Man page for "mysqld" command move to section 8 (bug#21220)

into  mysql.com:/Users/kent/mysql/bk/mysql-5.0-new

into  mysql.com:/Users/kent/mysql/bk/mysql-5.0-new

  Renamed variable, to avoid name clash with macro "rem_size"
  on AIX 5.3 and "/usr/include/sys/xmem.h" (bug#17648)
asn.cpp, asn.hpp:
  Avoid name clash with NAME_MAX

into  maint1.mysql.com:/data/localhome/tsmith/bk/global-50

into  moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0-bug16581

           'conc_sys' test

Concurrent execution of SELECT involing at least two INFORMATION_SCHEMA
tables, DROP DATABASE statement and DROP TABLE statement could have
resulted in stalled connection for this SELECT statement.

The problem was that for the first query of a join there was a race
between select from I_S.TABLES and DROP DATABASE, and the error (no
such database) was prepared to be send to the client, but the join
processing was continued.  On second query to I_S.COLUMNS there was a
race with DROP TABLE, but this error (no such table) was downgraded to
warning, and thd->net.report_error was reset.  And so neither result
nor error was sent to the client.

The solution is to stop join processing once it is clear we are going
to report a error, and also to downgrade to warnings file system errors
like 'no such database' (unless we are in the 'SHOW' command), because
I_S is designed not to use locks and the query to I_S should not abort
if something is dropped in the middle.

No test case is provided since this bug is a result of a race, and is
timing dependant.  But we test that plain SHOW TABLES and SHOW COLUMNS
give a error if there is no such database or a table respectively.

can be not replicable.

Now CREATE statements for writing in the binlog are created as follows:
  - the beginning of the statement is re-created;
  - the rest of the statement is copied from the original query.

The problem appears when there is a version-specific comment (produced by
mysqldump), started in the re-created part of the statement and closed in the
copied part -- there is closing comment-parenthesis, but there is no opening
one.

The proper fix could be to re-create original statement, but we can not
implement it in 5.0. So, for 5.0 the fix is just to cut closing
comment-parenthesis. This technique is also used for SHOW CREATE PROCEDURE
statement (so we are able to reuse existing code).

Fix for BUG#16676: Database CHARSET not used for stored procedures

The problem in BUG#16211 is that CHARSET-clause of the return type for
stored functions is just ignored.

The problem in BUG#16676 is that if character set is not explicitly
specified for sp-variable, the server character set is used instead
of the database one.

The fix has two parts:

  - always store CHARSET-clause of the return type along with the
    type definition in mysql.proc.returns column. "Always" means that
    CHARSET-clause is appended even if it has not been explicitly
    specified in CREATE FUNCTION statement (this affects BUG#16211 only).

    Storing CHARSET-clause if it is not specified is essential to avoid
    changing character set if the database character set is altered in
    the future.

    NOTE: this change is not backward compatible with the previous releases.

  - use database default character set if CHARSET-clause is not explicitly
    specified (this affects both BUG#16211 and BUG#16676).

    NOTE: this also breaks backward compatibility.

BUG#20761 is fixed.

into  moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0-main

Too many cursors (more than 1024) could lead to memory corruption.
This affects both, stored routines and C API cursors, and the
threshold is per-server, not per-connection.  Similarly, the
corruption could happen when the server was under heavy load
(executing more than 1024 simultaneous complex queries), and this is
the reason why this bug is fixed in 4.1, which doesn't support
cursors.

The corruption was caused by a bug in the temporary tables code, when
an attempt to create a table could lead to a write beyond allocated
space.  Note, that only internal tables were affected (the tables
created internally by the server to resolve the query), not tables
created with CREATE TEMPORARY TABLE.  Another pre-condition for the
bug is TRUE value of --temp-pool startup option, which, however, is a
default.

The cause of a bug was that random memory was overwritten in
bitmap_set_next() due to out-of-bound memory access.

into  moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0-main

into  siva.hindu.god:/usr/home/tim/m/bk/global-50

Too many cursors (more than 1024) could lead to memory corruption.
This affects both, stored routines and C API cursors, and the
threshold is per-server, not per-connection.  Similarly, the
corruption could happen when the server was under heavy load
(executing more than 1024 simultaneous complex queries), and this is
the reason why this bug is fixed in 4.1, which doesn't support
cursors.

The corruption was caused by a bug in the temporary tables code, when
an attempt to create a table could lead to a write beyond allocated
space.  Note, that only internal tables were affected (the tables
created internally by the server to resolve the query), not tables
created with CREATE TEMPORARY TABLE.  Another pre-condition for the
bug is TRUE value of --temp-pool startup option, which, however, is a
default.

The cause of a bug was that random memory was overwritten in
bitmap_set_next() due to out-of-bound memory access.