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

  Fixing a typo in the test case.


mysql-test/t/bigint.test:
  Fixing a typo in the test case.

into  moonbone.local:/mnt/gentoo64/work/24989-bug-5.0-opt-mysql


sql/ha_innodb.cc:
  Auto merged
sql/handler.cc:
  Auto merged
sql/sql_class.cc:
  Auto merged
sql/sql_class.h:
  Auto merged

When innodb detects a deadlock it calls ha_rollback_trans() to rollback the 
main transaction. But such action isn't allowed from inside of triggers and
functions. When it happen the 'Explicit or implicit commit' error is thrown
even if there is no commit/rollback statements in the trigger/function. This
leads to the user confusion.

Now the convert_error_code_to_mysql() function doesn't call the 
ha_rollback_trans() function directly but rather calls the
mark_transaction_to_rollback function and returns an error.
The sp_rcontext::find_handler() now doesn't allow errors to be caught by the
trigger/function error handlers when the thd->is_fatal_sub_stmt_error flag
is set. Procedures are still allowed to catch such errors.
The sp_rcontext::find_handler function now accepts a THD handle as a parameter.
The transaction_rollback_request and the is_fatal_sub_stmt_error flags are 
added to the THD class. The are initialized by the THD class constructor.
Now the ha_autocommit_or_rollback function rolls back main transaction
when not in a sub statement and the thd->transaction_rollback_request
is set.
The THD::restore_sub_statement_state function now resets the 
thd->is_fatal_sub_stmt_error flag on exit from a sub-statement.


sql/ha_innodb.cc:
  Bug#24989: The DEADLOCK error is improperly handled by InnoDB.
  Now the convert_error_code_to_mysql() function doesn't call the
  ha_rollback_trans() function directly but rather calls the
  mark_transaction_to_rollback function and returns an error.
sql/handler.cc:
  Bug#24989: The DEADLOCK error is improperly handled by InnoDB.
  Now the ha_autocommit_or_rollback function rolls back main transaction
  when not in a sub statement and the thd->transaction_rollback_request
  is set.
mysql-test/r/innodb-big.result:
  Added a test case for the bug#24989: The DEADLOCK error is improperly handled by
  InnoDB.
mysql-test/t/innodb-big.test:
  Added a test case for the bug#24989: The DEADLOCK error is improperly handled by
  InnoDB.
sql/sql_class.h:
  Bug#24989: The DEADLOCK error is improperly handled by InnoDB.
  The transaction_rollback_request and the is_fatal_sub_stmt_error flags are 
  added to the THD class.
sql/sql_class.cc:
  Bug#24989: The DEADLOCK error is improperly handled by InnoDB.
  Initialization of the transaction_rollback_request and the
  is_fatal_sub_stmt_error flags are added to the THD class constructor.
  The mark_transaction_to_rollback function is added.
  The THD::restore_sub_statement_state function now resets the
  thd->is_fatal_sub_stmt_error flag on exit from a sub-statement.
sql/sp_rcontext.h:
  Bug#24989: The DEADLOCK error is improperly handled by InnoDB.
  The sp_rcontext::find_handler function now accepts a THD handle as a parameter.
  The in_sub_stmt flag is added to the sp_rcontext class.
sql/sp_rcontext.cc:
  Bug#24989: The DEADLOCK error is improperly handled by InnoDB.
  The sp_rcontext::find_handler() now doesn't allow errors to be caught by the
  trigger/function error handlers when the thd->is_fatal_sub_stmt_error flag
  is set. Instead it tries to find a most inner procedure that isn't called
  directly or indirectly from any function/trigger.
  Procedures are still allowed to catch such errors.
  The sp_rcontext::find_handler function now accepts a THD handle as a parameter.

a place where it would not obstruct
correct multithreading.

into  moonbone.local:/mnt/gentoo64/work/29856-bug-5.0-opt-mysql


sql/sp_head.cc:
  Auto merged
mysql-test/r/query_cache.result:
  SCCS merged
mysql-test/t/query_cache.test:
  SCCS merged

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

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


sql/sql_base.cc:
  Auto merged
mysql-test/r/sp.result:
  Merge with local tree.
mysql-test/t/sp.test:
  Merge with local tree.

Using view columns by their names during an execution of
a prepared SELECT statement or a SELECT statement inside
a SP caused a memory leak.


sql/sql_base.cc:
  Fixed bug #29834.
  The find_field_in_view function has been modified to
  use the execution memory root for the Item_direct_view_ref
  objects allocation at non-first executions of
  a PS/SP instead of the statement memory.
mysql-test/t/sp.test:
  Updated test case for bug #29834.
mysql-test/r/sp.result:
  Updated test case for bug #29834.

into  moonbone.local:/mnt/gentoo64/work/30020-bug-5.0-opt-mysql

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

information schema table.

The get_schema_views_record() function fills records in the view table of
the informations schema with data about given views. Among other info
the is_updatable flag is set. But the check whether the view is updatable or
not wasn't covering all cases thus sometimes providing wrong info.
This might led to a user confusion.

Now the get_schema_views_record function additionally calls to the 
view->can_be_merge() function to find out whether the view can be updated or
not.


mysql-test/t/view.test:
  Added a test case for the bug#30020: Insufficient check led to a wrong info
  provided by the information schema table.
mysql-test/r/view.result:
  Added a test case for the bug#30020: Insufficient check led to a wrong info
  provided by the information schema table.
sql/sql_show.cc:
  Bug#30020: Insufficient check led to a wrong info provided by the
  information schema table.
  Now the get_schema_views_record function additionally calls to the 
  view->can_be_merge() function to find out whether the view can be updated or
  not.

The subst_spvars function is used to create query string with SP variables 
substituted with their values. This string is used later for the binary log
and for the query cache. The problem is that the
query_cache_send_result_to_client function requires some additional space
after the query to store database name and query cache flags. This 
space wasn't reserved by the subst_spvars function which led to a memory
corruption and crash.

Now the subst_spvars function reserves additional space for the query cache.


mysql-test/t/query_cache.test:
  Added a test case for the bug#29856: Insufficient buffer space led to a server crash.
mysql-test/r/query_cache.result:
  Added a test case for the bug#29856: Insufficient buffer space led to a server crash.
sql/sp_head.cc:
  Bug#29856: Insufficient buffer space led to a server crash.
  Now the subst_spvars function reserves additional space for the query cache.

into  mysql.com:/home/hf/work/29878/my50-29878

Item_func_user doesn't calculate anything in it's val_str() method,
just returns saved str_value.
Though Item::save_in_field method can destroy str_value, relying on
val_str() return. As a result we get the garbage stored in field.

We cannot use Item::save_in_field implementation for Item_func_user,
reimplement it in simpler way.


mysql-test/r/rpl_session_var.result:
  Bug #29878 Garbage data generation when executing SESSION_USER() on a slave.
  
  test result
mysql-test/t/rpl_session_var.test:
  Bug #29878 Garbage data generation when executing SESSION_USER() on a slave.
  
  test case
sql/item.cc:
  Bug #29878 Garbage data generation when executing SESSION_USER() on a slave.
  
  duplicating code moved to Item::save_str_in_field
sql/item.h:
  Bug #29878 Garbage data generation when executing SESSION_USER() on a slave.
  
  duplicating code moved to Item::save_str_in_field
sql/item_strfunc.h:
  Bug #29878 Garbage data generation when executing SESSION_USER() on a slave.
  
  Item_func_user::save_in_field implemented as simple storing str_value

into  mysql.com:/home/svoj/devel/mysql/BUG29957/mysql-5.0-engines

INSERT/DELETE/UPDATE followed by ALTER TABLE within LOCK TABLES
may cause table corruption on Windows.

That happens because ALTER TABLE writes outdated shared state
info into index file.

Fixed by removing obsolete workaround.

Affects MyISAM tables on Windows only.


myisam/mi_extra.c:
  On windows when mi_extra(HA_EXTRA_PREPARE_FOR_DELETE) is called,
  we release external lock and close index file. If we're in LOCK
  TABLES, MyISAM state info doesn't get updated until UNLOCK TABLES.
  
  That means when we release external lock and we're in LOCK TABLES,
  we may write outdated state info.
  
  As SQL layer closes all table instances, we do not need this
  workaround anymore.
mysql-test/r/alter_table.result:
  A test case for BUG#29957.
mysql-test/t/alter_table.test:
  A test case for BUG#29957.

into  mysql.com:/home/psergey/mysql-5.0-bdb-fix

 - make ha_berkeley::cmp_ref() take into account that auto-generated PKs 
   are stored in LSB-first order. 
 - Remove the temporary code that made the bugfix work for innodb only 


mysql-test/r/bdb.result:
  Adjust test-results.
sql/ha_berkeley.cc:
  BUG#28591: make the fix work for BDB tables too:
   - make ha_berkeley::cmp_ref() take into account that auto-generated PKs 
     are stored in LSB-first order.
sql/sql_select.cc:
  BUG#28591: Remove "innodb only" clause as the fix now works for BDB too
sql/table.cc:
  BUG#28591: Remove "innodb only" clause as the fix now works for BDB too

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

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


sql/sql_insert.cc:
  Auto merged

 the master but on the slave

MySQL can decide to "downgrade" a INSERT DELAYED statement
to normal insert in certain situations.
One such situation is when the slave is replaying a 
replication feed.
However INSERT DELAYED is logged even if there're no updates
whereas the NORMAL INSERT is not logged in such cases.

Fixed by always logging a "downgraded" INSERT DELAYED: even 
if there were no updates.


mysql-test/r/rpl_insert_delayed.result:
  Bug #29571: test case
mysql-test/t/rpl_insert_delayed.test:
  Bug #29571: test case
sql/sql_insert.cc:
  Bug #29571: log INSERT DELAYED even if it was 
  "downgraded" to INSERT (and there were no updates)

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.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).

  "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  bodhi.(none):/opt/local/work/mysql-5.0-runtime

---
fix compile on Windows for bug25714.c


tests/bug25714.c:
  fix compile on Windows

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.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''

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.0-axmrg


sql/sql_table.cc:
  Auto merged

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


mysql-test/t/innodb_mysql.test:
  Auto merged
sql/sql_select.cc:
  Auto merged
sql/table.cc:
  Auto merged
mysql-test/r/innodb_mysql.result:
  merge of 5.0-opt

into  mysql.com:/home/hf/work/29494/my41-29494