into  xiphis.org:/anubis/antony/work/mysql-5.1-engines.merge

into  pcg5ppc.xiphis.org:/Users/antony/Work/p1-bug29522.1

into  gleb.loc:/home/uchum/work/bk/5.1-opt

into  xiphis.org:/anubis/antony/work/p2-bug25679.3.merge-5.1

into  gleb.loc:/home/uchum/work/bk/5.1-opt

  Post-merge fix.

  Post-merge fix.

  "log.cc:1448: failed assertion `mysql_bin_log.is_open() && rex_data->empty()'"
  When Federated's transaction support was disabled by bug29875,
  this assertion became unreproducable.

into  gleb.loc:/home/uchum/work/bk/5.0-opt

into  gleb.loc:/home/uchum/work/bk/5.1-opt

into  xiphis.org:/anubis/antony/work/p2-bug25679.3.merge-5.1

  "Federated Denial of Service"
  Federated storage engine used to attempt to open connections within
  the ::create() and ::open() methods which are invoked while LOCK_open
  mutex is being held by mysqld. As a result, no other client sessions
  can open tables while Federated is attempting to open a connection.
  Long DNS lookup times would stall mysqld's operation and a rogue
  connection string which connects to a remote server which simply
  stalls during handshake can stall mysqld for a much longer period of
  time.
  This patch moves the opening of the connection much later, when the
  federated actually issues queries, by which time the LOCK_open mutex is
  no longer being held.

into  gleb.loc:/home/uchum/work/bk/5.0-opt

into  mysql.com:/home/svoj/devel/mysql/BUG29806/mysql-5.1-engines

Stopping mysql server could result in an entry in mysql error
file: "InnoDB: Error: MySQL is freeing a thd".

This happened because InnoDB assumes that the server will never
call external_lock(F_UNLCK) in case external_lock(READ/WRITE)
failed.

Prior to this patch we haven't had strict definition whether
external_lock(F_UNLCK) must be called in case external_lock(READ/WRITE)
fails.

This patch states that we never call external_lock(F_UNLCK) in case
external_lock(READ/WRITE) fails.

into  bodhi.(none):/opt/local/work/mysql-5.1-runtime

into  bodhi.(none):/opt/local/work/mysql-5.1-runtime

into  bodhi.(none):/opt/local/work/mysql-5.1-runtime

into  bodhi.(none):/opt/local/work/mysql-5.0-runtime

Merge pcg5ppc.xiphis.org:/private/Network/Servers/anubis.xiphis.org/home/antony/work/p2-bug25714.1.merge-5.0
into  pcg5ppc.xiphis.org:/private/Network/Servers/anubis.xiphis.org/home/antony/work/p2-bug25714.1.merge-5.1

---
fix compile on Windows for bug25714.c

Merge pcg5ppc.xiphis.org:/private/Network/Servers/anubis.xiphis.org/home/antony/work/p2-bug25714.1.merge-5.0
into  pcg5ppc.xiphis.org:/private/Network/Servers/anubis.xiphis.org/home/antony/work/p2-bug25714.1.merge-5.1

Merge pcg5ppc.xiphis.org:/private/Network/Servers/anubis.xiphis.org/home/antony/work/p2-bug25714.1.merge-5.0
into  pcg5ppc.xiphis.org:/private/Network/Servers/anubis.xiphis.org/home/antony/work/p2-bug25714.1.merge-5.1

When the SQL_BIG_RESULT flag is specified SELECT should store items from the
select list in the filesort data and use them when sending to a client.
The get_addon_fields function is responsible for creating necessary structures
for that. But this function was allowed to do so only for SELECT and
INSERT .. SELECT queries. This makes the SQL_BIG_RESULT useless for
the CREATE .. SELECT queries.

Now the get_addon_fields allows storing select list items in the filesort
data for the CREATE .. SELECT queries.

into  xiphis.org:/anubis/antony/work/p2-bug25714.1.merge-5.1

into  xiphis.org:/anubis/antony/work/p2-bug25714.1.merge-5.0

  "getGeneratedKeys() does not work with FEDERATED table"
  mysql_insert() expected the storage engine to update the row data
  during the write_row() operation with the value of the new auto-
  increment field. The field must be updated when only one row has
  been inserted as mysql_insert() would ignore the thd->last_insert.
  This patch implements HA_STATUS_AUTO support in ha_federated::info()
  and ensures that ha_federated::write_row() does update the row's
  auto-increment value.
  The test case was written in C as the protocol's 'id' value is
  accessible through libmysqlclient and not via SQL statements.
  mysql-test-run.pl was extended to enable running the test binary.

Changed the default location of the log output to LOG_FILE,
for backward compatibility with MySQL 5.0

into  magare.gmz:/home/kgeorge/mysql/autopush/B29644-5.0-opt

into  olga.mysql.com:/home/igor/mysql-5.0-opt

  Limit the fix for bug 28591 to InnoDB only

If a primary key is defined over column c of enum type then 
the EXPLAIN command for a look-up query of the form
  SELECT * FROM t WHERE c=0
said that the query was with an impossible where condition though the
query correctly returned non-empty result set when the table indeed 
contained rows with error empty strings for column c. 

This kind of misbehavior was due to a bug in the function 
Field_enum::store(longlong,bool) that erroneously returned 1 if
the the value to be stored was equal to 0. 
Note that the method 
Field_enum::store(const char *from,uint length,CHARSET_INFO *cs)
correctly returned 0 if a value of the error empty string 
was stored. 

into  chilla.local:/home/mydev/mysql-5.1-axmrg

into  chilla.local:/home/mydev/mysql-5.1-axmrg

into  chilla.local:/home/mydev/mysql-5.0-axmrg