Problem: when SHOW BINLOG EVENTS was issued, it increased the value of
@@session.max_allowed_packet. This allowed a non-root user to increase
the amount of memory used by her thread arbitrarily. Thus, it removes
the bound on the amount of system resources used by a client, so it
presents a security risk (DoS attack).

Fix: it is correct to increase the value of @@session.max_allowed_packet
while executing SHOW BINLOG EVENTS (see BUG 30435). However, the
increase should only be temporary. Thus, the fix is to restore the value
when SHOW BINLOG EVENTS ends.
The value of @@session.max_allowed_packet is also increased in
mysql_binlog_send (i.e., the binlog dump thread). It is not clear if this
can cause any trouble, since normally the client that issues
COM_BINLOG_DUMP will not issue any other commands that would be affected
by the increased value of @@session.max_allowed_packet. However, we
restore the value just in case.


mysql-test/suite/rpl/r/rpl_packet.result:
  update result file
mysql-test/suite/rpl/t/rpl_packet.test:
  Add test that verifies that @@session.max_allowed_packet does not change
  when issuing SHOW BINLOG EVENTS.
  Make previous sub-test clean up.
  Add comments listing the bugs in this test case.
sql/sql_repl.cc:
  Restore the old value of thd->variables.max_allowed_packet at the
  end of mysql_binlog_send and mysql_show_binlog_events.

> ------------------------------------------------------------
> revno: 3392.1.1
> revision-id: gshchepa@mysql.com-20100521184732-0jvpzinv0uwyvr2d
> parent: sven.sandberg@sun.com-20100520153801-yyhujm1qqa4eyfn0
> committer: Gleb Shchepa <gshchepa@mysql.com>
> branch nick: 53804-5.1
> timestamp: Fri 2010-05-21 22:47:32 +0400
> message:
>   Bug #53804: serious flaws in the alter database .. upgrade
>               data directory name command
>   
>   The check_db_name function has been modified to validate tails of
>   #mysql50#-prefixed database names for compliance with MySQL 5.0
>   database name encoding rules (the check_table_name function call
>   has been reused).

> ------------------------------------------------------------
> revno: 3386
> revision-id: sergey.glukhov@sun.com-20100518082821-yajhvbv1ghmlpu1n
> parent: aelkin@mysql.com-20100516170332-x8priwrdjwolc065
> committer: Sergey Glukhov <Sergey.Glukhov@sun.com>
> branch nick: mysql-5.1-bugteam
> timestamp: Tue 2010-05-18 13:28:21 +0500
> message:
>   Bug#48729 SELECT ... FROM INFORMATION_SCHEMA.ROUTINES causes memory to grow
>   Analysis showed that in case of accessing I_S table
>   ROUTINES we perform unnecessary allocations
>   with get_field() function for every processed row that
>   in their turn causes significant memory growth.
>   the fix is to avoid use of get_field().

> ------------------------------------------------------------
> revno: 3367 [merge]
> revision-id: joro@sun.com-20100504140328-srxf3c088j2twnq6
> parent: kristofer.pettersson@sun.com-20100503172109-f9hracq5pqsaomb1
> parent: joro@sun.com-20100503151651-nakknn8amrapmdp7
> committer: Georgi Kodinov <joro@sun.com>
> branch nick: B53371-5.1-bugteam
> timestamp: Tue 2010-05-04 17:03:28 +0300
> message:
>   Bug #53371: COM_FIELD_LIST can be abused to bypass table level grants.
>   
>   This is the 5.1 merge and extension of the fix.
>   The server was happily accepting paths in table name in all places a table
>   name is accepted (e.g. a SELECT). This allowed all users that have some 
>   privilege over some database to read all tables in all databases in all
>   mysql server instances that the server file system has access to.
>   Fixed by :
>   1. making sure no path elements are allowed in quoted table name when
>   constructing the path (note that the path symbols are still valid in table names
>   when they're properly escaped by the server).
>   2. checking the #mysql50# prefixed names the same way they're checked for
>   path elements in mysql-5.0.
> ------------------------------------------------------------
> Use --include-merges or -n0 to see merged revisions.

> ------------------------------------------------------------
> revno: 3351.41.1
> revision-id: alexey.kopytov@sun.com-20100430111048-jdls6ofn4kkmpt09
> parent: sergey.glukhov@sun.com-20100329134249-03wyhzp5k92dzhcb
> committer: Alexey Kopytov <Alexey.Kopytov@Sun.com>
> branch nick: my51-bug48419
> timestamp: Fri 2010-04-30 15:10:48 +0400
> message:
>   Bug #48419: another explain crash..
>   
>   WHERE predicates containing references to empty tables in a
>   subquery were handled incorrectly by the optimizer when
>   executing EXPLAIN. As a result, the optimizer could try to
>   evaluate such predicates rather than just stop with
>   "Impossible WHERE noticed after reading const tables" as 
>   it would do in a non-subquery case. This led to valgrind 
>   errors and crashes.
>   
>   Fixed the code checking the above condition so that subqueries
>   are not excluded and hence are handled in the same way as top
>   level SELECTs.

> ------------------------------------------------------------
> revno: 1810.3987.14
> revision-id: davi.arnaut@sun.com-20100429132816-ictyul6d75itek22
> parent: ramil@mysql.com-20100429044232-f0pkyx8fnpszf142
> committer: Davi Arnaut <Davi.Arnaut@Sun.COM>
> branch nick: 50974-5.0
> timestamp: Thu 2010-04-29 10:28:16 -0300
> message:
>   Bug#50974: Server keeps receiving big (> max_allowed_packet) packets indefinitely.
>   
>   The server could be tricked to read packets indefinitely if it
>   received a packet larger than the maximum size of one packet.
>   This problem is aggravated by the fact that it can be triggered
>   before authentication.
>   
>   The solution is to no skip big packets for non-authenticated
>   sessions. If a big packet is sent before a session is authen-
>   ticated, a error is returned and the connection is closed.

> ------------------------------------------------------------
> revno: 3363 [merge]
> revision-id: davi.arnaut@sun.com-20100429231819-i3anwzrdasjmezvt
> parent: davi.arnaut@sun.com-20100401131522-895y8uzvv8ag44gs
> parent: davi.arnaut@sun.com-20100429132816-ictyul6d75itek22
> committer: Davi Arnaut <Davi.Arnaut@Sun.COM>
> branch nick: mysql-5.1-bugteam
> timestamp: Thu 2010-04-29 20:18:19 -0300
> message:
>   Manual merge.
> ------------------------------------------------------------
> Use --include-merges or -n0 to see merged revisions.

> ------------------------------------------------------------
> revno: 1810.3987.13
> revision-id: ramil@mysql.com-20100429044232-f0pkyx8fnpszf142
> parent: alexey.kopytov@sun.com-20100426200600-op06qy98llzpzgl1
> committer: Ramil Kalimullin <ramil@mysql.com>
> branch nick: b53237-5.0-bugteam
> timestamp: Thu 2010-04-29 08:42:32 +0400
> message:
>   Fix for bug #53237: mysql_list_fields/COM_FIELD_LIST stack smashing
>   
>   Problem: "COM_FIELD_LIST is an old command of the MySQL server, before there was real move to only
>   SQL. Seems that the data sent to COM_FIELD_LIST( mysql_list_fields() function) is not
>   checked for sanity. By sending long data for the table a buffer is overflown, which can
>   be used deliberately to include code that harms".
>   
>   Fix: check incoming data length.

The patch did not apply cleanly:
- Line numbers are completely off, roughly it is 2030 -> 1313
- What is called "pend" in the patch, is "arg_end" in the source.

> revno: 3351.14.56
> committer: Marko Mdkeld <marko.makela@oracle.com>
> branch nick: 5.1-innodb
> timestamp: Mon 2010-04-26 14:08:56 +0300
> message:
>   Add a test case for Bug #52745.

> ------------------------------------------------------------
> revno: 3351.14.47
> revision-id: marko.makela@oracle.com-20100421095033-0acvzxb8um8cms0a
> parent: marko.makela@oracle.com-20100421094032-ir4glqk46qvg2ywn
> committer: Marko Mäkelä <marko.makela@oracle.com>
> branch nick: 5.1-innodb
> timestamp: Wed 2010-04-21 12:50:33 +0300
> message:
>   dtuple_convert_big_rec(): Store locally any fields whose maximum length
>   is less than 256 bytes. (Bug #52745)
>   Add related comments and debug assertions to the "offsets"
>   functions in rem0rec.c.
>   Approved by Sunny Bains

> ------------------------------------------------------------
> revno: 3351.47.2
> revision-id: marko.makela@oracle.com-20100511104910-nim8kgguawpis7zo
> parent: marko.makela@oracle.com-20100511104500-c6kzd0bg5s42p8e9
> committer: Marko Mäkelä <marko.makela@oracle.com>
> branch nick: mysql-5.1-innodb2
> timestamp: Tue 2010-05-11 13:49:10 +0300
> message:
>   btr_page_split_and_insert(): Add an assertion
>   suggested by Sunny Bains when reviewing Bug #52964.

> ------------------------------------------------------------
> revno: 3351.47.1
> revision-id: marko.makela@oracle.com-20100511104500-c6kzd0bg5s42p8e9
> parent: vasil.dimov@oracle.com-20100510132852-cz457uqvj8iiy9mm
> committer: Marko Mäkelä <marko.makela@oracle.com>
> branch nick: mysql-5.1-innodb2
> timestamp: Tue 2010-05-11 13:45:00 +0300
> message:
>   Remove a stray expression. Spotted by Sunny Bains.

> ------------------------------------------------------------
> revno: 3351.14.74
> revision-id: marko.makela@oracle.com-20100504093128-44v6glupe1dsh0ug
> parent: marko.makela@oracle.com-20100503122859-k73bl51re93o0mt4
> committer: Marko Mäkelä <marko.makela@oracle.com>
> branch nick: 5.1-innodb
> timestamp: Tue 2010-05-04 12:31:28 +0300
> message:
>   btr_page_split_and_insert(): Correct the fix of Bug #52964.
>   When split_rec==NULL, choose the correct node pointer key (first_rec).

> ------------------------------------------------------------
> revno: 3351.14.50
> revision-id: marko.makela@oracle.com-20100421185359-8qaxoa2yyrpzwdd7
> parent: marko.makela@oracle.com-20100421102723-0i80uezbyu0ekj5d
> committer: Marko Mäkelä <marko.makela@oracle.com>
> branch nick: 5.1-innodb
> timestamp: Wed 2010-04-21 21:53:59 +0300
> message:
>   btr_page_split_and_insert(): Avoid an infinite loop. (Bug #52964)
>   
>   btr_page_tuple_smaller(): New function, refactored from
>   btr_page_split_and_insert().
>   
>   btr_page_get_split_rec(): Renamed from btr_page_get_sure_split_rec().
>   Note that a NULL return may mean that the tuple is to be inserted into
>   either the lower or upper page, to be determined by btr_page_tuple_smaller().
>   
>   btr_page_split_and_insert(): When btr_page_get_split_rec() returns NULL,
>   invoke btr_page_tuple_smaller() to determine which half-page the tuple
>   belongs to.
>   
>   Reviewed by Sunny Bains

> ------------------------------------------------------------
> revno: 3362
> revision-id: davi.arnaut@sun.com-20100401131522-895y8uzvv8ag44gs
> parent: ramil@mysql.com-20100429045409-r7r5lcyiruis15v7
> committer: Davi Arnaut <Davi.Arnaut@Sun.COM>
> branch nick: 50755-5.1
> timestamp: Thu 2010-04-01 10:15:22 -0300
> message:
>   Bug#50755: Crash if stored routine def contains version comments
>   
>   The problem was that a syntactically invalid trigger could cause
>   the server to crash when trying to list triggers. The crash would
>   happen due to a mishap in the backup/restore procedure that should
>   protect parser items which are not associated with the trigger. The
>   backup/restore is used to isolate the parse tree (and context) of
>   a statement from the load (and parsing) of a trigger. In this case,
>   a error during the parsing of a trigger could cause the improper
>   backup/restore sequence.
>   
>   The solution is to properly restore the original statement context
>   before the parser is exited due to syntax errors in the trigger body.

result file differs on embedded

Field_time::get_date method does not initialize MYSQL_TIME::time_type field.
The fix is to init this field.


mysql-test/r/type_time.result:
  test case
mysql-test/t/type_time.test:
  test case
sql/field.cc:
  --use Field_time::get_time in Field_time::get_date
  --removed duplicated code in Field_time::get_date method

err_index could be not a member of the share structure or prebuilt
structure passed from MySQL. For now, we resort to the traditional
way of scanning index->table for the index number.

Add code to waiting for a set of errors.
Add code to waiting for an error instead of waiting for io thread to stop, as
after 'START SLAVE', the status of io thread is still not running.
But it doesn't mean slave io thread encounters an error.

without FOR UPDATE is causing a lock".

SELECT statements with subqueries referencing InnoDB tables
were acquiring shared locks on rows in these tables when they
were executed in REPEATABLE-READ mode and with statement or
mixed mode binary logging turned on.

This was a regression which were introduced when fixing
bug 39843.

The problem was that for tables belonging to subqueries
parser set TL_READ_DEFAULT as a lock type. In cases when
statement/mixed binary logging at open_tables() time this
type of lock was converted to TL_READ_NO_INSERT lock at
open_tables() time and caused InnoDB engine to acquire
shared locks on reads from these tables. Although in some
cases such behavior was correct (e.g. for subqueries in
DELETE) in case of SELECT it has caused unnecessary locking.

This patch implements minimal version of the fix for the
specific problem described in the bug-report which supposed
to be not too risky for pushing into 5.1 tree.
The 5.5 tree already contains a more appropriate solution
which also addresses other related issues like bug 53921
"Wrong locks for SELECTs used stored functions may lead
to broken SBR".

This patch tries to solve the problem by ensuring that
TL_READ_DEFAULT lock which is set in the parser for
tables participating in subqueries at open_tables()
time is interpreted as TL_READ_NO_INSERT or TL_READ.
TL_READ is used only if we know that this is a SELECT
and that this particular table is not used by a stored
function.

Test coverage is added for both InnoDB and MyISAM.

This patch introduces an "incompatible" change in locking
scheme for subqueries used in SELECT ... FOR UPDATE and
SELECT .. IN SHARE MODE.

In 4.1 (as well as in 5.0 and 5.1 before fix for bug 39843)
the server would use a snapshot InnoDB read for subqueries
in SELECT FOR UPDATE and SELECT .. IN SHARE MODE statements,
regardless of whether the binary log is on or off.

If the user required a different type of read (i.e. locking
read), he/she could request so explicitly by providing FOR
UPDATE/IN SHARE MODE clause for each individual subquery.

The patch for bug 39843 broke this behaviour (which was not
documented or tested), and started to use locking reads for
all subqueries in SELECT ... FOR UPDATE/IN SHARE MODE.
This patch restores 4.1 behaviour.

This patch should be mostly null-merged into 5.5 tree.

mysql-test/include/check_concurrent_insert.inc:
  Added auxiliary script which allows to check if statement
  reading table allows concurrent inserts in it.
mysql-test/include/check_no_concurrent_insert.inc:
  Added auxiliary script which allows to check that statement
  reading table doesn't allow concurrent inserts in it.
mysql-test/include/check_no_row_lock.inc:
  Added auxiliary script which allows to check if statement
  reading table doesn't take locks on its rows.
mysql-test/include/check_shared_row_lock.inc:
  Added auxiliary script which allows to check if statement
  reading table takes shared locks on some of its rows.
mysql-test/r/bug39022.result:
  After bug #46947 'Embedded SELECT without FOR UPDATE is
  causing a lock' was fixed test case for bug 39022 has to
  be adjusted in order to trigger execution path on which
  original problem was encountered.
mysql-test/r/innodb_mysql_lock2.result:
  Added coverage for handling of locking in various cases when
  we read data from InnoDB tables (includes test case for
  bug #46947 'Embedded SELECT without FOR UPDATE is causing a
  lock').
mysql-test/r/lock_sync.result:
  Added coverage for handling of locking in various cases when
  we read data from MyISAM tables.
mysql-test/t/bug39022.test:
  After bug #46947 'Embedded SELECT without FOR UPDATE is
  causing a lock' was fixed test case for bug 39022 has to
  be adjusted in order to trigger execution path on which
  original problem was encountered.
mysql-test/t/innodb_mysql_lock2.test:
  Added coverage for handling of locking in various cases when
  we read data from InnoDB tables (includes test case for
  bug #46947 'Embedded SELECT without FOR UPDATE is causing a
  lock').
mysql-test/t/lock_sync.test:
  Added coverage for handling of locking in various cases when
  we read data from MyISAM tables.
sql/mysql_priv.h:
  Function read_lock_type_for_table() now takes pointers to
  LEX and TABLE_LIST elements as its arguments since to
  correctly determine lock type it needs to know what
  statement is being performed and whether table element for
  which lock type to be determined belongs to prelocking list.
sql/sql_base.cc:
  Changed read_lock_type_for_table() to return a weak TL_READ
  type of lock in cases when we are executing SELECT (and so
  won't update tables directly) and table doesn't belong to
  statement's prelocking list and thus can't be used by a
  stored function. It is OK to do so since in this case table
  won't be used by statement or function call which will be
  written to the binary log, so serializability requirements
  for it can be relaxed.
  One of results from this change is that SELECTs on InnoDB
  tables no longer takes shared row locks for tables which
  are used in subqueries (i.e. bug #46947 is fixed).
  Another result is that for similar SELECTs on MyISAM tables
  concurrent inserts are allowed.
  In order to implement this change signature of
  read_lock_type_for_table() function was changed to
  take pointers to LEX and TABLE_LIST objects.
sql/sql_update.cc:
  Function read_lock_type_for_table() now takes pointers to
  LEX and TABLE_LIST elements as its arguments since to
  correctly determine lock type it needs to know what
  statement is being performed and whether table element for
  which lock type to be determined belongs to prelocking list.

list a thread doing a wait_ex as an s-lock waiter.

There are two problems:
1. In simplify_joins function we calculate table dependencies. If STRAIGHT_JOIN hint
is used for whole SELECT we do not count it and as result some dependendecies
might be lost. It leads to incorrect table order which is returned by
join_tab_cmp_straight() function.
2. make_join_statistics() calculate the transitive closure for relations a particular
JOIN_TAB is 'dependent on'.
We aggregate the dependent table_map of a JOIN_TAB by adding dependencies from other
tables which we depend on. However, this may also cause new dependencies to be
available after we have completed processing a certain JOIN_TAB.
Both these problems affect condition pushdown and as result condition might be pushed
into wrong table which leads to crash or even omitted which leads to wrong result.
The fix:
1. Use modified 'transitive closure' algorithm provided by Ole John Aske
2. Update table dependences in simplify_joins according to 
   global STRAIGHT_JOIN hint.
Note: the patch also fixes bugs 46091 & 51492


mysql-test/r/join_outer.result:
  test case
mysql-test/t/join_outer.test:
  test case
sql/sql_select.cc:
  1. Use modified 'transitive closure' algorithm provided by Ole John Aske
  2. Update table dependences in simplify_joins according to 
     global STRAIGHT_JOIN hint.

Removed misleading comments.

after fast alter table added unique key". Look up MySQL index number should
go through index translation table.

rb://347, approved by Marko