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.
 

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

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

Please see worklog for details on files changed.

into  example.com:/work/mysql-5.1-maint

Implementing event based replication of LC_TIME_NAMES for 5.0
(as a replacement of previously made ONE_SHOT replication)

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