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

Reset master before next test.

                    expired timeout on debx86-b in PB 

Moved the resource-intensive test case for bug #41486 into 
a separate test file to reduce execution time for mysql.test. 

LOAD_FILE
            
LOAD_FILE is not safe to replicate in STATEMENT mode, because it
depends on a file (which is loaded on master and may not exist in
slave(s)). This leads to scenarios on which the slave replicates the
statement with 'load_file' and it will try to load the file from local
file system. Given that the file may not exist in the slave filesystem
the operation will not succeed (probably returning NULL), causing
master and slave(s) to diverge. However, when using MIXED mode
replication, this can be made to work, if the statement including
LOAD_FILE is marked as unsafe, triggering a switch to ROW mode,
meaning that the contents of the file are written to binlog as row
events. Consequently, the contents from the file in the master will
reach the slave via the binlog.
           
This patch addresses this bug by marking the load_file function as
unsafe. When in mixed mode and when LOAD_FILE is issued, there will be
a switch to row mode. Furthermore, when in statement mode, the
LOAD_FILE will raise a warning that the statement is unsafe in that
mode.