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


mysql-test/t/create.test:
  Auto merged
sql/field.cc:
  Auto merged
sql/sql_base.cc:
  Auto merged
sql/table.cc:
  Auto merged
mysql-test/r/create.result:
  Merge with 5.0-opt.

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


storage/federated/ha_federated.cc:
  Auto merged

sql/ha_federated.cc:
  remote_error_number is set to -1 when an error was already reported
  with my_error(). ER(-1) will also cause a crash on 64bit arch and only
  worked on 32bit arch by luck

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


mysql-test/r/sp.result:
  Auto merged
mysql-test/t/create.test:
  Auto merged
sql/field.cc:
  Auto merged
sql/sql_base.cc:
  Auto merged
sql/sql_lex.cc:
  Auto merged
sql/sql_lex.h:
  Auto merged
sql/table.cc:
  Auto merged
mysql-test/r/create.result:
  Merge with 5.1 (main).

  Post-merge fix.


sql/sql_select.cc:
  Post-merge fix.
sql/table.cc:
  Post-merge fix.

  Post-merge fix.


sql/sql_select.cc:
  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.


mysql-test/t/disabled.def:
  bug29522
    reenable federated_innodb test

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


mysql-test/t/create.test:
  Auto merged
sql/field.cc:
  Auto merged
sql/sql_base.cc:
  Auto merged
sql/table.cc:
  Auto merged
mysql-test/r/create.result:
  Merge with 5.0 (main).

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


mysql-test/r/having.result:
  Auto merged
mysql-test/t/create.test:
  Auto merged
mysql-test/t/having.test:
  Auto merged
sql/field.cc:
  Auto merged
sql/sql_select.cc:
  Auto merged
mysql-test/include/mix1.inc:
  Merge with 5.0-opt.
mysql-test/r/create.result:
  Merge with 5.0-opt.
mysql-test/r/innodb_mysql.result:
  Merge with 5.0-opt.
mysql-test/r/type_enum.result:
  Merge with 5.0-opt.
mysql-test/t/type_enum.test:
  Merge with 5.0-opt.
sql/filesort.cc:
  Merge with 5.0-opt.
sql/sql_base.cc:
  Merge with 5.0-opt.
sql/table.cc:
  Merge with 5.0-opt.
storage/innobase/handler/ha_innodb.cc:
  Merge with 5.0-opt.

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


mysql-test/r/federated.result:
  Auto merged
mysql-test/t/federated.test:
  Auto merged
storage/federated/ha_federated.h:
  Auto merged
storage/federated/ha_federated.cc:
  manual merge 5.0 to 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.


mysql-test/r/federated.result:
  change of test/results due to patch for bug25679
mysql-test/t/federated.test:
  change of test/results due to patch for bug25679
sql/ha_federated.cc:
  bug25679
    remove function check_foreign_fata_source()
    ha_federated::open() no longer opens the federated connection.
    ha_federated::create() no longer opens and tests connection.
    ha_federated::real_connect() opens connection and tests presence of table.
    ha_federated::real_query() sends query, calling real_connect() if neccessary.
sql/ha_federated.h:
  bug25679
    new methods real_query() and real_connect()

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

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


sql/ha_ndbcluster.cc:
  Auto merged
sql/lock.cc:
  Auto merged

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.


mysql-test/suite/binlog/t/disabled.def:
  Re-enabled binlog_innodb and binlog_killed tests.
sql/ha_ndbcluster.cc:
  Restore handler state in case external_lock() failed.
sql/ha_partition.cc:
  Do not call external_lock(F_UNLCK) in case external_lock(READ/WRITE) failed.
sql/lock.cc:
  Do not call external_lock(F_UNLCK) in case external_lock(READ/WRITE) failed.
storage/myisammrg/myrg_locking.c:
  Restore handler state in case external_lock() failed.

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


tests/bug25714.c:
  fix compile on Windows

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


BitKeeper/deleted/.del-CMakeLists.txt~5:
  Auto merged

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.


mysql-test/t/create.test:
  Added a test case for the bug#15130: CREATE .. SELECT was denied to use
  advantages of the SQL_BIG_RESULT.
mysql-test/r/create.result:
  Added a test case for the bug#15130: CREATE .. SELECT was denied to use
  advantages of the SQL_BIG_RESULT.
sql/filesort.cc:
  Bug#15130: CREATE .. SELECT was denied to use advantages of the SQL_BIG_RESULT.
  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


mysql-test/mysql-test-run.pl:
  Auto merged
tests/Makefile.am:
  Auto merged
storage/federated/ha_federated.cc:
  manual merge from 5.0 to 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.


mysql-test/mysql-test-run.pl:
  bug25714
    implement support to run C test for bug25714
sql/ha_federated.cc:
  bug25714
    The storage engine instance property auto_increment_value was not
    being set.
    mysql_insert() requires that the storage engine updates the row with
    the auto-increment value, especially when only inserting one row.
    Implement support for ha_federated::info(HA_STATUS_AUTO)
tests/Makefile.am:
  bug25714
    build C test for bug
mysql-test/include/have_bug25714.inc:
  New BitKeeper file ``mysql-test/include/have_bug25714.inc''
mysql-test/r/federated_bug_25714.result:
  New BitKeeper file ``mysql-test/r/federated_bug_25714.result''
mysql-test/r/have_bug25714.require:
  New BitKeeper file ``mysql-test/r/have_bug25714.require''
mysql-test/t/federated_bug_25714.test:
  New BitKeeper file ``mysql-test/t/federated_bug_25714.test''
tests/bug25714.c:
  New BitKeeper file ``tests/bug25714.c''

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


mysql-test/r/log_state.result:
  Changed the default location of the log output to LOG_FILE,
  for backward compatibility with MySQL 5.0
sql/set_var.cc:
  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


sql/ha_innodb.cc:
  Auto merged
sql/sql_base.cc:
  Auto merged
mysql-test/r/innodb_mysql.result:
  5.0-opt merge
mysql-test/t/innodb_mysql.test:
  5.0-opt merge

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

  Limit the fix for bug 28591 to InnoDB only


sql/sql_select.cc:
  Limit the fix for bug 28591 to InnoDB only
sql/table.cc:
  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. 


mysql-test/r/type_enum.result:
  Added a test case for bug #29661.
mysql-test/t/type_enum.test:
  Added a test case for bug #29661.
sql/field.cc:
  Fixed bug #29611.
  If a primary key was 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


sql/sql_table.cc:
  Auto merged

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

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


sql/sql_table.cc:
  Auto merged