into  mats-laptop.(none):/home/bk/b36197-mysql-5.1-bugteam

When flushing tables, there were a slight chance that the flush was occuring
between processing of two table map events. Since the tables are opened
one by one, it might result in that the tables were not valid and that sub-
sequent locking of tables would cause the slave to crash.

The problem is solved by opening and locking all tables at once using
simple_open_n_lock_tables(). Also, the patch contain a change to open_tables()
so that pre-locking only takes place when the trg_event_map is not zero, which
was not the case before (this caused the lock to be placed in thd->locked_tables
instead of thd->lock since the assumption was that triggers would be called
later and therefore the tables should be pre-locked).

into  mysql1000.(none):/home/andrei/MySQL/BARE/mysql-5.1-release

  Add ChangeLog if it exists
  - Removed separate 'normal+rowrepl' test run, not needed any longer
  - Removed separate 'rpl' test run, included in main test run already
  - Renamed some test "comments", to use similar naming style
  - Limited one of the Cluster test runs to 'ndb' and 'rpl_ndb' suites
  - Reordered test runs, to be aligned with Windows test runs
mysql.spec.sh:
  - No longer including the "Example" storage engine
  - Added to configure "--without-ENGINE" if not to compile engine as plugin

Among two claimed artifacts the critical one is in that the Table map of 
a query following the failing with a duplicate key error CREATE-SELECT is skipped from
instantionating (and thus binlogging). That leads to sending a "chopped" group of the data
row-events without the table map head to the slave. 
The slave can not apply the only data row events.
It's not easy to force the slave to react with an error in such a case (the second complaint
on the bug report), because the lack of a table Rows_log_event::do_apply_event the data row event
handler is a common situation which  normally designates the event has to be filtered out
basing on the repliation do/ingore rules decision.

Fixed: table map creating and binlogging is restored via deploying the standard cleanup call in
select_create::abort().
No error is reported if by chance the table map was not been binlogged.
Leaving this out to resolve with considering how to combine the do/ingore rules with the situation
when erronoulsy the Table_map is not written to binlog.

Problem: SELECTs prohibited for a transactional SE in autocommit mode
if read_only is set.

Fix: allow them.

The problem is that when upgrading the event table, the sql_mode
column was always being added instead of being updated to list new
sql_mode values, causing upgrades of the event which already have
a sql_mode column to not be updated to the new sql_mode values.

The solution is to always add first a stub sql_mode column and
subsequently update the column to the new sql_mode values.

  If excluding Federated, make sure dynamic plugin is not built
Makefile.am:
  Only run cluster test when compiled with cluster
lib_sql.cc:
  Work around for Visual Studio 2003, that lacks vsnprintf() but has _vsnprintf()

  Corrects build problems embedded on Windows
Makefile.am:
  Install .sym or mysqld-debug if exists
query_cache_debug.test, query_cache_debug.result:
  Set more resonable query cache size (bug#35749)
CMakeLists.txt:
  Added missing stacktrace.c

into  five.local.lan:/work/mysql-5.1-24-rc

Problems were caused by modifications of
- the server
  - HANDLER FOR SQLSTATE '00000' is now rejected (bug fix)
    affects several ..._storedproc* tests
  - improved error message
    affects the ..._trig_03e
  - improved content of information_schema.COLUMNS about
    information_schema.REFERENTIAL_CONSTRAINTS
    affects is_columns_is
- the content of the community build (collations)
    affects charset_collation_3 

into  pippilotta.erinye.com:/shared/home/df/mysql/build/mysql-5.1.24-release

  Made Federated and Cluster optional

  Disabled 'rpl_redirect', failure is sporadic and and the test is superfluous
rpl_packet.test, rpl_packet.result:
  Removing race conditions from rpl_packet causing test to fail

into  magare.gmz:/home/kgeorge/mysql/work/merge-build-5.1-bugteam

into  mats-laptop.(none):/home/bk/b29020-mysql-5.1-rpl

tables is not zero any more. For row-based logging, there is an extra commit
for sending rows changed by the statement to the binary log.

into  magare.gmz:/home/kgeorge/mysql/work/merge-build-5.1-bugteam

into  magare.gmz:/home/kgeorge/mysql/work/merge-build-5.1-bugteam

into  magare.gmz:/home/kgeorge/mysql/work/merge-build-5.1-bugteam

into  amd64.(none):/src/bug26243/my51-bug26243

into  mysql1000.(none):/home/andrei/MySQL/MERGE/5.1-main2rpl

If a binlog file is manually replaced with a namesake directory the internal purging did
not handle the error of deleting the file so that eventually
a post-execution guards fires an assert.

Fixed with reusing a snippet of code for bug@18199 to tolerate lack of the file but no other error 
at an attempt to delete it.
The same applied to the index file deletion.

The cset carries pieces of manual merging.

into  macbook.gmz:/Users/kgeorge/mysql/work/pb-5.1-bugteam

into  macbook.gmz:/Users/kgeorge/mysql/work/pb-5.1-bugteam

into  mysql1000.(none):/home/andrei/MySQL/MERGE/5.1-main2rpl

into  mysql1000.(none):/home/andrei/MySQL/MERGE/5.1-main2rpl

into  macbook.gmz:/Users/kgeorge/mysql/work/pb-5.1-bugteam

into  amd64.(none):/src/bug26243/my51-bug26243

into  amd64.(none):/src/bug26243/my51-bug26243

into  quad.opbmk:/mnt/raid/alik/MySQL/devel/5.1-bt-merged