The test uses show binlog event which is not deterministic due to the single insert delayed
query can generate up to number of inserted rows row-events pair (table_map + Write_row)

The solution is to leave the current binlogging behaviour as it is and change 
the test as spliting arguments of insert delayed query. Note, that such fix was applied
earlier for  binlog_insert_delayed.test :
https://intranet.mysql.com/secure/apps/irclog.php?channel=22&start_time=2006-09-27 

There are no tests with insert delayed and show binlog events combination requiring
this fix.

into  suse.vabb.com:/home/Chuck/development/mysql-5.1-new-rpl

This patch is an additional code change to the get_str_len_and_pointer 
method in log_events.cc. This change is necessary to correct a problem
encountered on 64-bit SUSE where the auto_increment_* variables were
being overwritten. The change corrects a cast mismatch which caused
the problem.

correctly in some cases", from 5.0.
In short, calls to a stored function located in another database
than the default database, may fail to replicate if the call was made
by SET, SELECT, or DO.
sp_head.cc automerged, only the test and test's result had to be hand-merged.

into  gbichot3.local:/home/mysql_src/mysql-5.1-rpl-19725

correctly in some cases".
In short, calls to a stored function located in another database
than the default database, may fail to replicate if the call was made
by SET, SELECT, or DO.
Longer: when a stored function is called from a statement which does not go
to binlog ("SET @A=somedb.myfunc()", "SELECT somedb.myfunc()",
"DO somedb.myfunc()"), this crafted statement is binlogged:
"SELECT myfunc();" (accompanied with a mention of the default database
if there is one). So, if "somedb" is not the default database,
the slave would fail to find myfunc(). The fix is to specify the
function's database name in the crafted binlogged statement, like this:
"SELECT somedb.myfunc();". Test added in rpl_sp.test.

On loaded boxes it is possible a INSERT with sleep of 1.5s to take
more time.

Adding "flush log" before running mysqlbinlog.

  After merge fix

Adding "flush logs" to fix test failure.

into  romeo.(none):/home/bkroot/mysql-5.1-new-rpl

Post-merge fixes.

into  mysql.com:/usr/home/bar/mysql-5.1.b17642

into  romeo.(none):/home/bk/merge-b22864-myql-5.1-new-rpl

from log):
When row-based logging is used, the CREATE-SELECT is written as two
parts: as a CREATE TABLE statement and as the rows for the table. For
both transactional and non-transactional tables, the CREATE TABLE
statement was written to the transaction cache, as were the rows, and
on statement end, the entire transaction cache was written to the binary
log if the table was non-transactional. For transactional tables, the
events were kept in the transaction cache until end of transaction (or
statement that were not part of a transaction).

For the case when AUTOCOMMIT=0 and we are creating a transactional table
using a create select, we would then keep the CREATE TABLE statement and
the rows for the CREATE-SELECT, while executing the following statements.
On a rollback, the transaction cache would then be cleared, which would
also remove the CREATE TABLE statement. Hence no table would be created
on the slave, while there is an empty table on the master.

This relates to BUG#22865 where the table being created exists on the
master, but not on the slave during insertion of rows into the newly
created table. This occurs since the CREATE TABLE statement were still
in the transaction cache until the statement finished executing, and
possibly longer if the table was transactional.

This patch changes the behaviour of the CREATE-SELECT statement by
adding an implicit commit at the end of the statement when creating
non-temporary tables. Hence, non-temporary tables will be written to the
binary log on completion, and in the even of AUTOCOMMIT=0, a new
transaction will be started. Temporary tables do not commit an ongoing
transaction: neither as a pre- not a post-commit.

The events for both transactional and non-transactional tables are
saved in the transaction cache, and written to the binary log at end
of the statement.

into  mysql.com:/usr/home/bar/mysql-5.1.b22645

into  mysql.com:/usr/home/bar/mysql-5.0.b22645

Problem: mysqlbinlog_base64 failed sporadically.

Reason: Missing "flush logs" before running $MYSQL_BINLOG,
which could start dumping the log file before server
has finished writting into it.
Fix:
- implementing --force-if-open option to "mysqlbinlog"
- adding --disable-force-if-open to make $MYSQL_BINLOG
  fail on non-closed log files, to garantee that nobody
  will forget "flush logs" in the future.
- adding "flush logs" into all affected tests.

into  mysql.com:/usr/home/bar/mysql-5.1.b20396v2

into  romeo.(none):/home/bkroot/mysql-5.1-new-rpl

into  mysql.com:/home/bk/MERGE/mysql-5.1-merge

into  mysql.com:/home/bk/MERGE/mysql-5.0-merge

into  mysql.com:/home/bk/MERGE/mysql-5.1-merge

into  mysql.com:/home/bk/MERGE/mysql-5.0-merge

into  mysql.com:/home/bk/MERGE/mysql-4.1-merge

into  quant.(none):/ext/mysql/bk/mysql-5.0-bug24507

into  mysql.com:/usr/home/bar/mysql-5.1.b20396

into  mysql.com:/usr/home/bar/mysql-5.0.b24158

into  quant.(none):/ext/mysql/bk/mysql-5.0-bug24507

The problem was located to lie inside current NPTL pthread_exit() 
implementation. Race conditions in this code can lead to segmentation
fault. Hovewer, this can happen only in a race between first thread 
calling pthread_exit() and other threads. 

Workaround implemented in this patch spawns a dummy thread, which
exits immediately, during thread lib initialization. This will exclude
segment violations when further threads exit.