> ------------------------------------------------------------
> revno: 2871.4.1
> revision-id: vvaintroub@mysql.com-20090429115110-1ye4700m8it5tyc5
> parent: staale.smedseng@sun.com-20090428161955-3vnku1igwt0knpfu
> committer: Vladislav Vaintroub <vvaintroub@mysql.com>
> branch nick: mysql-5.1-bugteam
> timestamp: Wed 2009-04-29 13:51:10 +0200
> message:
>   Bug#43932 myisam index corruption with large index and large 
>   key_buffer_size.
>   
>   The cause of corruption was number overflow when multiplying 
>   two ulong values, number of used keycache blocks with size
>   of a single block. The result of multiplication exceeded ulong 
>   range (4G) and this lead to incorrectly calculated  buffer offset
>   in the key cache.
>   
>   The fix is to use size_t for multiplication result.
>   
>   This patch also fixes pointless cast in safemalloc 
>   (size of allocated block to uint), that creates lot of false
>   alarm warnings when using big keycache (> 4GB) in debug mode.

> ------------------------------------------------------------
> revno: 2857.1.8
> revision-id: sergey.glukhov@sun.com-20090417084627-yvt63k51vvvjbx9j
> parent: anurag.shekhar@sun.com-20090417055354-7vw80v1rwn0z1tt4
> parent: sergey.glukhov@sun.com-20090417074115-dv9h5ijalj2hgq3r
> committer: Sergey Glukhov <Sergey.Glukhov@sun.com>
> branch nick: mysql-5.1-bugteam
> timestamp: Fri 2009-04-17 13:46:27 +0500
> message:
>   5.0-bugteam->5.1-bugteam merge
>     ------------------------------------------------------------
>     revno: 1810.3882.12
>     revision-id: sergey.glukhov@sun.com-20090417074115-dv9h5ijalj2hgq3r
>     parent: patrick.crews@sun.com-20090416174744-u9fxu6ophud91a1h
>     committer: Sergey Glukhov <Sergey.Glukhov@sun.com>
>     branch nick: mysql-5.0-bugteam
>     timestamp: Fri 2009-04-17 12:41:15 +0500
>     message:
>       Bug#44151 using handler commands on information_schema tables crashes server
>       information schema tables are based on internal tmp tables which are removed
>       after each statement execution. So HANDLER comands can not be used with
>       information schema.

> ------------------------------------------------------------
> revno: 2857.1.1
> revision-id: satya.bn@sun.com-20090415114608-26b21dtx3doeidcc
> parent: davi.arnaut@sun.com-20090414120532-9a34lwlk105z8log
> committer: Satya B <satya.bn@sun.com>
> branch nick: mysql-5.1-bugteam-innodb
> timestamp: Wed 2009-04-15 17:16:08 +0530
> message:
>   Applying InnoDB snashot 5.1-ss4699, part 1. Fixes BUG#39320 and other
>   problems
>   
>   1) BUG#39320 - innodb crash in file btr/btr0pcur.c line 217 with 
>                  innodb_locks_unsafe_for_binlog
>   
>   2) Fixes bug in multi-table semi consistent reads.
>   
>   3) Fixes email address from dev@innodb.com to innodb_dev_ww@oracle.com
>   
>   4) Fixes warning message generated by main.innodb test
>   
>   
>   Detailed revision comments:
>   
>   r4399 | marko | 2009-03-12 09:38:05 +0200 (Thu, 12 Mar 2009) | 5 lines
>   branches/5.1: row_sel_get_clust_rec_for_mysql(): Store the cursor position
>   also for unlock_row().  (Bug #39320)
>   
>   rb://96 approved by Heikki Tuuri.
>   
>   r4400 | marko | 2009-03-12 10:06:44 +0200 (Thu, 12 Mar 2009) | 8 lines
>   branches/5.1: Fix a bug in multi-table semi-consistent reads.
>   Remember the acquired record locks per table handle (row_prebuilt_t)
>   rather than per transaction (trx_t), so that unlock_row should successfully
>   unlock all non-matching rows in multi-table operations.
>   This deficiency was found while investigating Bug #39320.
>   
>   rb://94 approved by Heikki Tuuri.
>   
>   r4481 | marko | 2009-03-19 15:01:48 +0200 (Thu, 19 Mar 2009) | 6 lines
>   branches/5.1: row_unlock_for_mysql(): Do not unlock records that were
>   modified by the current transaction.  This bug was introduced or unmasked
>   in r4400.
>   
>   rb://97 approved by Heikki Tuuri
>   
>   r4573 | vasil | 2009-03-30 14:17:13 +0300 (Mon, 30 Mar 2009) | 4 lines
>   branches/5.1:
>   
>   Fix email address from dev@innodb.com to innodb_dev_ww@oracle.com
>   
>   r4574 | vasil | 2009-03-30 14:27:08 +0300 (Mon, 30 Mar 2009) | 38 lines
>   branches/5.1:
>   
>   Restore the state of INNODB_THREAD_CONCURRENCY to silence this warning:
>   
>     TEST                                      RESULT   TIME (ms)
>     ------------------------------------------------------------
>     
>     worker[1] Using MTR_BUILD_THREAD 250, with reserved ports 12500..12509
>     main.innodb                              [ pass ]   8803
>     
>     MTR's internal check of the test case 'main.innodb' failed.
>     This means that the test case does not preserve the state that existed
>     before the test case was executed.  Most likely the test case did not
>     do a proper clean-up.
>     This is the diff of the states of the servers before and after the
>     test case was executed:
>     mysqltest: Logging to '/tmp/autotest.sh-20090330_033000-5.1.5Hg8CY/mysql-5.1/mysql-test/var/tmp/check-mysqld_1.log'.
>     mysqltest: Results saved in '/tmp/autotest.sh-20090330_033000-5.1.5Hg8CY/mysql-5.1/mysql-test/var/tmp/check-mysqld_1.result'.
>     mysqltest: Connecting to server localhost:12500 (socket /tmp/autotest.sh-20090330_033000-5.1.5Hg8CY/mysql-5.1/mysql-test/var/tmp/mysqld.1.sock) as 'root', connection 'default', attempt 0 ...
>     mysqltest: ... Connected.
>     mysqltest: Start processing test commands from './include/check-testcase.test' ...
>     mysqltest: ... Done processing test commands.
>     --- /tmp/autotest.sh-20090330_033000-5.1.5Hg8CY/mysql-5.1/mysql-test/var/tmp/check-mysqld_1.result	2009-03-30 14:12:31.000000000 +0300
>     +++ /tmp/autotest.sh-20090330_033000-5.1.5Hg8CY/mysql-5.1/mysql-test/var/tmp/check-mysqld_1.reject	2009-03-30 14:12:41.000000000 +0300
>     @@ -99,7 +99,7 @@
>      INNODB_SUPPORT_XA	ON
>      INNODB_SYNC_SPIN_LOOPS	20
>      INNODB_TABLE_LOCKS	ON
>     -INNODB_THREAD_CONCURRENCY	8
>     +INNODB_THREAD_CONCURRENCY	16
>      INNODB_THREAD_SLEEP_DELAY	10000
>      INSERT_ID	0
>      INTERACTIVE_TIMEOUT	28800
>     
>     mysqltest: Result content mismatch
>     
>     not ok
>   
>   r4576 | vasil | 2009-03-30 16:25:10 +0300 (Mon, 30 Mar 2009) | 4 lines
>   branches/5.1:
>   
>   Revert a change to Makefile.am that I committed accidentally in c4574.

> ------------------------------------------------------------
> revno: 2852.2.3
> revision-id: davi.arnaut@sun.com-20090403194600-60ufn0tz1gx1kl0l
> parent: gni@mysql.com-20090403184200-vnjtpsv4an79w8bu
> parent: davi.arnaut@sun.com-20090403191154-0ho2nai3chjsmpof
> committer: Davi Arnaut <Davi.Arnaut@Sun.COM>
> branch nick: 43230-5.1
> timestamp: Fri 2009-04-03 16:46:00 -0300
> message:
>   Merge Bug#43230 into mysql-5.1-bugteam
>     ------------------------------------------------------------
>     revno: 1810.3855.16
>     revision-id: davi.arnaut@sun.com-20090403191154-0ho2nai3chjsmpof
>     parent: chad@mysql.com-20090402152928-3ld60a56h86njcpg
>     committer: Davi Arnaut <Davi.Arnaut@Sun.COM>
>     branch nick: 43230-5.0
>     timestamp: Fri 2009-04-03 16:11:54 -0300
>     message:
>       Bug#43230: SELECT ... FOR UPDATE can hang with FLUSH TABLES WITH READ LOCK indefinitely
>       
>       The problem is that a SELECT .. FOR UPDATE statement might open
>       a table and later wait for a impeding global read lock without
>       noticing whether it is holding a table that is being waited upon
>       the the flush phase of the process that took the global read
>       lock.
>       
>       The same problem also affected the following statements:
>       
>       LOCK TABLES .. WRITE
>       UPDATE .. SET (update and multi-table update)
>       TRUNCATE TABLE ..
>       LOAD DATA ..
>       
>       The solution is to make the above statements wait for a impending
>       global read lock before opening the tables. If there is no
>       impending global read lock, the statement raises a temporary
>       protection against global read locks and progresses smoothly
>       towards completion.
>       
>       Important notice: the patch does not try to address all possible
>       cases, only those which are common and can be fixed unintrusively
>       enough for 5.0.

> ------------------------------------------------------------
> revno: 2852.2.1
> revision-id: gni@mysql.com-20090403182157-de6ecrtzlgvpl5mk
> parent: timothy.smith@sun.com-20090402083720-b7i3jr4dmvwjakcj
> committer: Guangbao Ni <gni@mysql.com>
> branch nick: bugteam-5.1-bug42640
> timestamp: Fri 2009-04-03 18:21:57 +0000
> message:
>   BUG#42640 mysqld crashes when unsafe statements are executed (STRICT_TRANS_TABLESmode)
>   
>   Mysql server crashes because unsafe statements warning is wrongly elevated to error,
>   which is set the error status of Diagnostics_area of the thread in THD::binlog_query().
>   Yet the caller believes that binary logging shouldn't touch the status, so it will
>   set the status also later by my_ok(), my_error() or my_message() seperately
>   according to the execution result of the statement or transaction.
>   But the status of Diagnostics_area of the thread is allowed to set only once.
>   
>   Fixed to clear the error wrongly set by binary logging, but keep the warning message.

> ------------------------------------------------------------
> revno: 2852.12.6
> tags: clone-5.1.35-build, mysql-5.1.35
> revision-id: gshchepa@mysql.com-20090513075139-g50shsfjaf1dstdn
> parent: joerg@mysql.com-20090508190407-ymqxmp6daeta6fdj
> committer: Gleb Shchepa <gshchepa@mysql.com>
> branch nick: mysql-5.1
> timestamp: Wed 2009-05-13 12:51:39 +0500
> message:
>   Bug #44290: explain crashes for subquery with distinct in
>               SQL_SELECT::test_quick_select
>   
>   The crash was caused by an incomplete cleanup of JOIN_TAB::select
>   during the filesort of rows for GROUP BY clause inside a subquery.
>   Queries where a quick index access is replaced with filesort was
>   was affected. For example:
>   
>     SELECT 1 FROM
>       (SELECT COUNT(DISTINCT c1) FROM t1
>          WHERE c2 IN (1, 1) AND c3 = 2 GROUP BY c2) x
>   
>   Quick index access related data in the SQL_SELECT::test_quick_select
>   function was inconsistent after an incomplete cleanup.
>   This function has been completed to prevent crashes in the
>   SQL_SELECT::test_quick_select function.

> ------------------------------------------------------------
> revno: 2852.1.15
> revision-id: davi.arnaut@sun.com-20090409152525-b4vnj9atidmjh0mf
> parent: luis.soares@sun.com-20090409113044-2072kufy5efeohpp
> committer: Davi Arnaut <Davi.Arnaut@Sun.COM>
> branch nick: 43706-5.1
> timestamp: Thu 2009-04-09 12:25:25 -0300
> message:
>   Bug#43706: libmysqld segfaults when re-intialised
>   Bug#44091: libmysqld gets stuck waiting on mutex on initialization
>   
>   The problem was that libmysqld wasn't enforcing a certain
>   initialization and deinitialization order for the mysys
>   library. Another problem was that the global object used
>   for management of log event handlers (aka LOGGER) wasn't
>   being prepared for a possible reutilization.
>   
>   What leads to the hang/crash reported is that a failure
>   to load the language file triggers a double call of the
>   cleanup functions, causing an already destroyed mutex to
>   be used.
>   
>   The solution is enforce a order on the initialization and
>   deinitialization of the mysys library within the libmysqld
>   library and to ensure that the global LOGGER object reset
>   it's internal state during cleanup.

> ------------------------------------------------------------
> revno: 2852.1.10
> revision-id: sergey.glukhov@sun.com-20090409093850-z3vgmz8fqogv8o1o
> parent: v.narayanan@sun.com-20090409081823-zsw611isjcorl63b
> parent: sergey.glukhov@sun.com-20090409091931-2zhtgonllfmsxjex
> committer: Sergey Glukhov <Sergey.Glukhov@sun.com>
> branch nick: mysql-5.1-bugteam
> timestamp: Thu 2009-04-09 14:38:50 +0500
> message:
>   5.0-bugteam->5.1-bugteam merge
>     ------------------------------------------------------------
>     revno: 1810.3882.6
>     revision-id: sergey.glukhov@sun.com-20090409091931-2zhtgonllfmsxjex
>     parent: anurag.shekhar@sun.com-20090409080004-xvxy663jan45tb3c
>     committer: Sergey Glukhov <Sergey.Glukhov@sun.com>
>     branch nick: mysql-5.0-bugteam
>     timestamp: Thu 2009-04-09 14:19:31 +0500
>     message:
>       Bug#43833 Simple INSERT crashes the server
>       The crash happens due to wrong 'digits' variable value(0),
>       'digits' can not be 0, so the fix is use 1 as min allowed value.

> ------------------------------------------------------------
> revno: 2841.1.1
> revision-id: sergey.glukhov@sun.com-20090401084033-161k4f8qucafy6mj
> parent: ramil@mysql.com-20090401053459-07x8z2pw2ev94xck
> committer: Sergey Glukhov <Sergey.Glukhov@sun.com>
> branch nick: mysql-5.1-bugteam
> timestamp: Wed 2009-04-01 13:40:33 +0500
> message:
>   Bug#43183 ExctractValue() brings result list in missorder
>   The problem is that XML functions(items) do not reset null_value
>   before their execution and further item excution may use
>   null_value value of the previous result.
>   The fix is to reset null_value.

> ------------------------------------------------------------
> revno: 1810.3885.1
> revision-id: holyfoot@mysql.com-20090428094726-i4j7z985mxr43jym
> parent: gshchepa@mysql.com-20090428001913-plzojd1pwplior44
> committer: Alexey Botchkov <holyfoot@mysql.com>
> branch nick: 50mrg
> timestamp: Tue 2009-04-28 14:47:26 +0500
> message:
>   Bug#38990 Arbitrary data input plus GIS functions causes mysql server crash 
>      the Point() and Linestring() functions create WKB representation of an
>      object instead of an real geometry object.
>      That produced bugs when these were inserted into tables.
>   
>      GIS tests fixed accordingly.
>               
>   per-file messages:
>     mysql-test/r/gis-rtree.result
>   Bug#38990 Arbitrary data input plus GIS functions causes mysql server crash 
>       test result
>     mysql-test/r/gis.result
>   Bug#38990 Arbitrary data input plus GIS functions causes mysql server crash 
>       test result
>     mysql-test/t/gis-rtree.test
>   Bug#38990 Arbitrary data input plus GIS functions causes mysql server crash 
>       test fixed - GeomFromWKB invocations removed
>     mysql-test/t/gis.test
>   Bug#38990 Arbitrary data input plus GIS functions causes mysql server crash 
>       test fixed - AsWKB invocations added
>     sql/item_geofunc.cc
>   Bug#38990 Arbitrary data input plus GIS functions causes mysql server crash 
>        Point() and similar functions to create a proper object

Test was flakey on some machines and showed spurious
reds for races.

New-and-improved test makes do with fewer statements,
no mysqltest-variables, and no backticks. Should hope-
fully be more robust. Heck, it's debatable whether we
should have a test for this, anyway.

It leads to crash because there is no OOM check in ha_archive::unpack_row().
The fix:
added OOM error check

compilation warning fixed

due to name_const substitution

Problem:
"In general, statements executed within a stored procedure
are written to the binary log using the same rules that
would apply were the statements to be executed in standalone
fashion. Some special care is taken when logging procedure
statements because statement execution within procedures
is not quite the same as in non-procedure context".

For example, each reference to a local variable in SP's
statements is replaced by NAME_CONST(var_name, var_value).
Queries like
"CREATE TABLE ... SELECT FUNC(local_var ..."
are logged as
"CREATE TABLE ... SELECT FUNC(NAME_CONST("local_var", var_value) ..."
that leads to differrent field names and
might result in "Incorrect column name" if var_value is long enough.

Fix: in 5.x we'll issue a warning in such a case.
In 6.0 we should get rid of NAME_CONST().

Note: this issue and change should be described in the documentation
("Binary Logging of Stored Programs").

manual merge. also adds test specific to 5.1+

Fine-tuning. Broke out comparison into method by
suggestion of Davi. Clarified comments. Reverting
test-case which I find too brittle; proper test
case in 5.1+.

(Pushing for Azundris)
      
We allow security-contexts with NULL users (for
system-threads and for unauthenticated users).
If a non-SUPER-user tried to KILL such a thread,
we tried to compare the user-fields to see whether
they owned that thread. Comparing against NULL was
not a good idea.
      
If KILLer does not have SUPER-privilege, we
specifically check whether both KILLer and KILLee
have a non-NULL user before testing for string-
equality. If either is NULL, we reject the KILL.

            
The issue happened to be two-fold.
The table map event was recorded into binlog having
an incorrect size when number of columns exceeded 251. 
The Row-based event had incorrect recording and restoring m_width member within
the same as above conditions.

Fixed with correcting m_data_size and m_width.

                    expired timeout on debx86-b in PB

Turned off general log when importing DB dump in the test 
case for bug #41486 due to the bug in CSV engine code that 
makes logging long SQL query too slow.