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

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

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

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

  1. Use 'dat' extension, because it is handled in Makefile.am;
  2. Fix typo: the bug id is 35469, not 35649.

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

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

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

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

- Backported the 5.1 DBUG to 5.0.
- Avoid memory cleanup race on Windows client for CTRL-C

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

into  moonbone.local:/work/27219-bug-5.1

into  mysql.com:/home/ram/work/mysql-5.1-bugteam

The problem was that LOAD DATA code (sql_load.cc) didn't take into
account that there may be items, representing references to other
columns. This is a usual case in views. The crash happened because
Item_direct_view_ref was casted to Item_user_var_as_out_param,
which is not a base class.

The fix is to
  1) Handle references properly;
  2) Ensure that an item is treated as a user variable only when
     it is a user variable indeed;
  3) Report an error if LOAD DATA is used to load data into
     non-updatable column.

after few delete statements

Problem: changing a file size might require that it must be 
unmapped beforehand.
  
Fix: unmap the file before changing its size.

into  moonbone.local:/work/27219-bug-5.1

into  witty.:/Users/mattiasj/clones/bug21413-51-bugteam

into  witty.:/Users/mattiasj/clones/bug21413-50-bugteam

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

into  witty.:/Users/mattiasj/clones/bug21413-51-engines

into  witty.:/Users/mattiasj/clones/bug21413-50-engines

            in REPLACE DELAYED
    
post push patch, removing the optimization for
copying delayed_insert variables.

The bug allow multiple executing transactions working with non-transactional
to interfere with each others by interleaving the events of different trans-
actions.

Bug is fixed by writing non-transactional events to the transaction cache and
flushing the cache to the binary log at statement commit. To mimic the behavior
of normal statement-based replication, we flush the transaction cache in row-
based mode when there is no committed statements in the transaction cache,
which means we are committing the first one. This means that it will be written
to the binary log as a "mini-transaction" with just the rows for the statement.

Note that the changes here does not take effect when building the server with
HAVE_TRANSACTIONS set to false, but it is not clear if this was possible before
this patch either.

For row-based logging, we also have that when AUTOCOMMIT=1, the code now always
generates a BEGIN/COMMIT pair for single statements, or BEGIN/ROLLBACK pair in the
case of non-transactional changes in a statement that was rolled back. Note that
for the case where changes to a non-transactional table causes a rollback due
to error, the statement will now be logged with a BEGIN/ROLLBACK pair, even
though some changes has been committed to the non-transactional table.

into  moonbone.local:/work/27219-5.0-opt-mysql

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

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

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

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

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

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

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

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