sql/event_data_objects.cc:
  Fix typo.

(Bug#26338 "events_bugs.test fail on Debian")


mysql-test/r/events_bugs.result:
  Update results.
mysql-test/t/events_bugs.test:
  Make a stab at fixing events_bugs.test failure on Debian.
  The problem is purely in the race inherent in the test case: an
  event that was started doesn't go away fast enough and clutters the 
  processlist. This patch remove the part of the event that
  we can not wait on synchronously (there is no table 'hashed_num'
  referenced anywhere).

open bug report, reproduced in the runtime team tree).


sql/event_data_objects.cc:
  Make a stub at fixing a race in event_bugs.test under valgrind:
  read of uninitialized byte in SHOW PROCESSLIST from an event thread.

into  vajra.(none):/opt/local/work/mysql-5.1-21483


sql/sql_insert.cc:
  Auto merged

sql/sql_insert.cc:
  Do not access delayed thread memory without a mutex.

sql/sql_insert.cc:
  Correct a merge error (wrong declaration was used).

into  vajra.(none):/opt/local/work/mysql-5.1-21483


sql/sp_head.cc:
  Auto merged
sql/sql_base.cc:
  Auto merged
sql/sql_lex.h:
  Auto merged
mysql-test/r/insert.result:
  Manual merge.
mysql-test/t/insert.test:
  Manual merge.
sql/sql_insert.cc:
  Manual merge.

into  vajra.(none):/opt/local/work/mysql-5.0-21483


sql/sp_head.cc:
  Auto merged
sql/sql_base.cc:
  Auto merged
sql/sql_insert.cc:
  Auto merged
sql/sql_lex.h:
  Auto merged

Bug#21483 "Server abort or deadlock on INSERT DELAYED with another
implicit insert"
Also fixes and adds test cases for bugs:
20497 "Trigger with INSERT DELAYED causes Error 1165"
21714 "Wrong NEW.value and server abort on INSERT DELAYED to a
table with a trigger".
Post-review fixes.

Problem:
In MySQL INSERT DELAYED is a way to pipe all inserts into a
given table through a dedicated thread. This is necessary for
simplistic storage engines like MyISAM, which do not have internal
concurrency control or threading and thus can not
achieve efficient INSERT throughput without support from SQL layer.
DELAYED INSERT works as follows:
For every distinct table, which can accept DELAYED inserts and has
pending data to insert, a dedicated thread is created to write data
to disk. All user connection threads that attempt to
delayed-insert into this table interact with the dedicated thread in
producer/consumer fashion: all records to-be inserted are pushed
into a queue of the dedicated thread, which fetches the records and 
writes them.
In this design, client connection threads never open or lock
the delayed insert table.
This functionality was introduced in version 3.23 and does not take 
into account existence of triggers, views, or pre-locking.
E.g. if INSERT DELAYED is called from a stored function, which,
in turn, is called from another stored function that uses the delayed
table, a deadlock can occur, because delayed locking by-passes
pre-locking. Besides:
 * the delayed thread works directly with the subject table through
   the storage engine API and does not invoke triggers
 * even if it was patched to invoke triggers, if triggers,
   in turn, used other tables, the delayed thread would
   have to open and lock involved tables (use pre-locking).
 * even if it was patched to use pre-locking, without deadlock
   detection the delayed thread could easily lock out user 
   connection threads in case when the same table is used both
   in a trigger and on the right side of the insert query: 
   the delayed thread would not release locks until all inserts 
   are complete, and user connection can not complete inserts 
   without having locks on the tables used on the right side of the
   query.

Solution:

These considerations suggest two general alternatives for the
future of INSERT DELAYED:
 * it is considered a full-fledged alternative to normal INSERT
 * it is regarded as an optimisation that is only relevant 
   for simplistic engines.
Since we missed our chance to provide complete support of new
features when 5.0 was in development, the first alternative
currently renders infeasible.
However, even the second alternative, which is to detect
new features and convert DELAYED insert into a normal insert, 
is not easy to implement.
The catch-22 is that we don't know if the subject table has triggers
or is a view before we open it, and we only open it in the
delayed thread. We don't know if the query involves pre-locking
until we have opened all tables, and we always first create
the delayed thread, and only then open the remaining tables.
This patch detects the problematic scenarios and converts
DELAYED INSERT to a normal INSERT using the following approach:
 * if the statement is executed under pre-locking (e.g. from
   within a stored function or trigger) or the right
   side may require pre-locking, we detect the situation
   before creating a delayed insert thread and convert the statement
   to a conventional INSERT.
  * if the subject table is a view or has triggers, we shutdown
   the delayed thread and convert the statement to a conventional
   INSERT.


mysql-test/r/insert.result:
  Update test results.
mysql-test/t/insert.test:
  Add a test case for Bug#21483, Bug#20497, Bug#21714 (INSERT DELAYED
  and stored routines, triggers).
sql/sp_head.cc:
  Upgrade lock type to TL_WRITE when computing the pre-locking set.
sql/sql_base.cc:
  Use a new method.
sql/sql_insert.cc:
  INSERT DELAYED and pre-locking:
  - if  under pre-locking, upgrade the lock type to TL_WRITE
  and proceed as a normal write
  - if DELAYED table has triggers, also request a lock upgrade.
  - make sure errors in the delayed thread are propagated
  correctly
sql/sql_lex.h:
  Add a method to check if a parsed tree refers to stored
  routines.

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


sql/item.cc:
  Auto merged
sql/item_func.cc:
  Auto merged
sql/mysql_priv.h:
  Auto merged
sql/set_var.cc:
  Auto merged
sql/sql_class.h:
  Auto merged
sql/sql_insert.cc:
  Auto merged
sql/sql_parse.cc:
  Auto merged
sql/sql_prepare.cc:
  Auto merged
sql/sql_yacc.yy:
  Auto merged
mysql-test/t/disabled.def:
  Manual merge.

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


mysql-test/include/mix1.inc:
  Auto merged
mysql-test/r/innodb_mysql.result:
  Auto merged
mysql-test/r/ps_1general.result:
  Auto merged
mysql-test/t/disabled.def:
  Auto merged
mysql-test/t/ps_1general.test:
  Auto merged
sql/ha_ndbcluster.cc:
  Auto merged
sql/ha_ndbcluster_binlog.cc:
  Auto merged
sql/item.cc:
  Auto merged
sql/item_func.cc:
  Auto merged
sql/mysql_priv.h:
  Auto merged
sql/set_var.cc:
  Auto merged
sql/sql_base.cc:
  Auto merged
sql/sql_cache.cc:
  Auto merged
sql/sql_class.cc:
  Auto merged
sql/sql_class.h:
  Auto merged
sql/sql_lex.cc:
  Auto merged
sql/sql_lex.h:
  Auto merged
sql/sql_parse.cc:
  Auto merged
sql/sql_partition.cc:
  Auto merged
sql/sql_prepare.cc:
  Auto merged
sql/sql_table.cc:
  Auto merged
sql/sql_yacc.yy:
  Auto merged
sql/table.h:
  Auto merged
sql/sql_insert.cc:
  SCCS merged

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

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


sql/item.cc:
  Auto merged
sql/item_func.cc:
  Auto merged
sql/mysql_priv.h:
  Auto merged
sql/set_var.cc:
  Auto merged
sql/sql_class.h:
  Auto merged
sql/sql_insert.cc:
  Auto merged
sql/sql_parse.cc:
  Auto merged
sql/sql_prepare.cc:
  Auto merged
sql/sql_yacc.yy:
  Auto merged

into  vajra.(none):/opt/local/work/mysql-4.1-runtime

into  mockturtle.local:/home/dlenev/src/mysql-5.1-cts-3

TABLES" and failures of alter_table.test on Windows which occured after
pushing fix for bugs #20662, #20903, #24508, #24738 (various problems
with CREATE TABLE SELECT).

ALTER TABLE statements which were handled using "fast" alter table
optimization were not properly working under LOCK TABLES if table
was transactional (for all table types under Windows).

Code implementing "fast" version of ALTER TABLE tried to open and
lock table using open_ltable() after renaming .FRM files (which
corresponds to renaming tables in normal case) in some cases
(for transactional tables or on Windows). This caused problems
under LOCK TABLES and conflicted with name-lock taken by 
ALTER TABLE RENAME on target tables.

This patch solves this issue by using reopen_name_locked_table()
instead of open_ltable().


mysql-test/include/mix1.inc:
  Added test for bug #28415 "Some ALTER TABLE statements no longer work
  under LOCK TABLES" and minimal coverage for fast ALTER TABLE behaviour
  for transactional tables.
mysql-test/r/innodb_mysql.result:
  Added test for bug #28415 "Some ALTER TABLE statements no longer work
  under LOCK TABLES" and minimal coverage for fast ALTER TABLE behaviour
  for transactional tables.
sql/sql_table.cc:
  mysql_alter_table():
    Fixed handling of transactional tables (and all tables on Windows)
    by "fast" ALTER TABLE.
    Code implementing "fast" version of ALTER TABLE tried to open and
    lock table using open_ltable() after renaming .FRM files (which
    corresponds to renaming tables in normal case) for such tables.
    This caused problems under LOCK TABLES and conflicted with name-lock
    taken by ALTER TABLE RENAME on target tables. We solve this issue by
    using reopen_name_locked_table() instead of open_ltable().

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


sql/sql_insert.cc:
  Manual merge.

sql/sql_insert.cc:
  Fix a compile-time warning (log_on is not used in embedded).

into  bk-internal.mysql.com:/data0/bk/mysql-5.1-opt


sql/field.cc:
  Auto merged

into  bk-internal.mysql.com:/data0/bk/mysql-5.0-opt

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


mysql-test/r/subselect3.result:
  Auto merged
sql/item_subselect.cc:
  Auto merged
sql/sql_select.h:
  Auto merged

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


mysql-test/t/grant.test:
  Auto merged
mysql-test/r/grant.result:
  Manual merge

a crash when the left operand of the predicate is evaluated to NULL.
It happens when the rows from the inner tables (tables from the subquery)
are accessed by index methods with key values obtained by evaluation of
the left operand of the subquery predicate. When this predicate is
evaluated to NULL an alternative access with full table scan is used
to check whether the result set returned by the subquery is empty or not.
The crash was due to the fact the info about the access methods used for
regular key values was not properly restored after a switch back from the
full scan access method had occurred.
The patch restores this info properly.
The same problem existed for queries with IN subquery predicates if they
were used not at the top level of the queries.


mysql-test/r/subselect3.result:
  Added a test case for bug #28375.
mysql-test/t/subselect3.test:
  Added a test case for bug #28375.
sql/item_subselect.cc:
  Fixed bug #28375: a query with an NOT IN subquery predicate may cause
  a crash when the left operand of the predicate is evaluated to NULL.
  It happens when the rows from the inner tables (tables from the subquery)
  are accessed by index methods with key values obtained by evaluation of
  the left operand of the subquery predicate. When this predicate is
  evaluated to NULL an alternative access with full table scan is used
  to check whether the result set returned by the subquery is empty or not.
  The crash was due to the fact the info about the access methods used for
  regular key values was not properly restored after a switch back from the
  full scan access method had occurred.
  The patch restores this info properly.
sql/sql_select.h:
  Fixed bug #28375: a query with an NOT IN subquery predicate may cause
  a crash when the left operand of the predicate is evaluated to NULL.
  In the JOIN_TAB structure two fields have been added to save info about
  index methods used to access the subquery rows. The saved info is used
  after a switch back from the alternative full scan access method has 
  occurred. The full scan is used when the left operand of the subquery
  predicate is evaluated to NULL.

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

  Corrected test case for the bug#27878.


mysql-test/t/grant.test:
  Corrected test case for the bug#27878.
mysql-test/r/grant.result:
  Corrected test case for the bug#27878.

into  mockturtle.local:/home/dlenev/src/mysql-5.1-cts-3


sql/sp_head.cc:
  Auto merged

into  mysql.com:/home/hf/work/27957/my51-27957


mysql-test/t/grant.test:
  Auto merged
mysql-test/r/grant.result:
  merging
sql/sql_update.cc:
  Auto merged
sql/sql_prepare.cc:
  Auto merged

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

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

database.

If a user has a right to update anything in the current database then the 
access was granted and further checks of access rights for underlying tables
wasn't done correctly. The check is done before a view is opened and thus no
check of access rights for underlying tables can be carried out.
This allows a user to update through a view a table from another database for
which he hasn't enough rights.

Now the mysql_update() and the mysql_test_update() functions are forces
re-checking of access rights after a view is opened.


mysql-test/t/grant.test:
  Added a test case for the bug#27878: Unchecked privileges on a view referring to a table from another database.
mysql-test/r/grant.result:
  Added a test case for the bug#27878: Unchecked privileges on a view referring to a table from another database.
sql/sql_update.cc:
  Bug#27878: Unchecked privileges on a view referring to a table from another 
  database.
  Now the mysql_update() function forces re-checking of access rights after 
  the view is opened.
sql/sql_prepare.cc:
  Bug#27878: Unchecked privileges on a view referring to a table from another 
  database.
  Now the mysql_test_update() function forces re-checking of access rights after
  the view is opened.

mysql-test/r/insert_update.result:
  result fixed
mysql-test/r/type_newdecimal.result:
  result fixed