------------------------------------------------------------
revno: 3314
tags: clone-5.1.43-build
committer: Georgi Kodinov <joro@sun.com>
branch nick: merge-5.1-bugteam
timestamp: Fri 2010-01-15 10:51:39 +0200
message:
  merge of version change.
  Added not_embedded to the new dbug_sync test file.
    ------------------------------------------------------------
    revno: 1810.3974.22
    committer: Georgi Kodinov <joro@sun.com>
    branch nick: merge-5.0-bugteam
    timestamp: Thu 2010-01-14 10:24:02 +0200
    message:
      version change
------------------------------------------------------------
revno: 3313
committer: Martin Hansson <martin.hansson@sun.com>
branch nick: 5.1bt-commit
timestamp: Wed 2010-01-13 12:38:06 +0100
message:
  Merge of fix for Bug#48157.
    ------------------------------------------------------------
    revno: 3311.1.4
    committer: Ramil Kalimullin <ramil@mysql.com>
    branch nick: mysql-5.1-bugteam
    timestamp: Wed 2010-01-13 15:08:48 +0400
    message:
      Auto-merge.
        ------------------------------------------------------------
        revno: 3311.2.5
        committer: Georgi Kodinov <joro@sun.com>
        branch nick: merge-5.1-bugteam
        timestamp: Wed 2010-01-13 12:47:42 +0200
        message:
          merge
        ------------------------------------------------------------
        revno: 3311.2.4
        committer: Georgi Kodinov <joro@sun.com>
        branch nick: merge-5.1-bugteam
        timestamp: Wed 2010-01-13 12:43:07 +0200
        message:
          version change
        ------------------------------------------------------------
        revno: 3311.2.3
        committer: Georgi Kodinov <joro@sun.com>
        branch nick: merge-5.1-bugteam
        timestamp: Wed 2010-01-13 12:28:42 +0200
        message:
          merge 5.1-main to 5.1-bugteam
        ------------------------------------------------------------
        revno: 3236.1.9
        committer: Kent Boortz <kent.boortz@sun.com>
        branch nick: mysql-5.1
        timestamp: Wed 2009-12-30 23:26:49 +0100
        message:
          Merge
            ------------------------------------------------------------
            revno: 3236.2.2
            committer: Kent Boortz <kent.boortz@sun.com>
            branch nick: mysql-5.1.42-release
            timestamp: Wed 2009-12-30 23:06:14 +0100
            message:
              Removed unwanted Perl DBI dependency
            ------------------------------------------------------------
            revno: 3236.2.1
            tags: mysql-5.1.42
            committer: MySQL Build Team <build@mysql.com>
            branch nick: mysql-5.1.42-release
            timestamp: Wed 2009-12-16 14:21:02 +0100
            message:
              Merge
        ------------------------------------------------------------
        revno: 3236.1.8
        committer: Ramil Kalimullin <ramil@mysql.com>
        branch nick: mysql-5.1-pe-stage
        timestamp: Tue 2009-12-15 21:08:21 +0400
        message:
          Fix for bug#49517: Inconsistent behavior while using 
          NULLable BIGINT and INT columns in comparison
          
          Problem: a consequence of the fix for 43668.
          Some Arg_comparator inner initialization missed,
          that may lead to unpredictable (wrong) comparison
          results.
          
          Fix: always properly initialize Arg_comparator
          before its usage.
        ------------------------------------------------------------
        revno: 3236.1.7
        committer: Georgi Kodinov <joro@sun.com>
        branch nick: merge-5.1-pe-stage
        timestamp: Tue 2009-12-15 11:03:24 +0200
        message:
          Bug #48985: show create table crashes if previous access to the table 
            was killed
          
          Merge the fix from 5.1-bugteam to 5.1-main
        ------------------------------------------------------------
        revno: 3236.1.6
        committer: Georgi Kodinov <joro@sun.com>
        branch nick: merge-5.1-pe-stage
        timestamp: Tue 2009-12-15 10:54:53 +0200
        message:
          Bug#49489: Uninitialized cache led to a wrong result.
          
          Merge the fix from 5.1-bugteam to 5.1-main
        ------------------------------------------------------------
        revno: 3236.1.5
        committer: Georgi Kodinov <joro@sun.com>
        branch nick: merge-5.1-pe-stage
        timestamp: Tue 2009-12-15 10:37:10 +0200
        message:
          Bug #49480: WHERE using YEAR columns returns unexpected results
          
          Merge the fix from 5.1-bugteam to 5.1-main
        ------------------------------------------------------------
        revno: 3236.1.4
        author: sunanda.menon@sun.com
        committer: MySQL Build Team <build@mysql.com>
        branch nick: mysql-5.1
        timestamp: Tue 2009-12-08 10:26:11 +0100
        message:
          Null-merge from mysql-5.1.40sp1-release
            ------------------------------------------------------------
            revno: 3138.8.21
            tags: mysql-5.1.40sp1
            committer: MySQL Build Team <build@mysql.com>
            branch nick: mysql-5.1.40sp1-release
            timestamp: Wed 2009-11-25 23:43:37 +0100
            message:
              Patch adjustments
            ------------------------------------------------------------
            revno: 3138.8.20
            committer: MySQL Build Team <build@mysql.com>
            branch nick: mysql-5.1.40sp1-release
            timestamp: Wed 2009-11-25 23:24:18 +0100
            message:
              Patch adjustments
            ------------------------------------------------------------
            revno: 3138.8.19
            committer: MySQL Build Team <build@mysql.com>
            branch nick: mysql-5.1.40sp1-release
            timestamp: Wed 2009-11-25 18:21:48 +0100
            message:
              Test cases added
            ------------------------------------------------------------
            revno: 3138.8.18
            committer: MySQL Build Team <build@mysql.com>
            branch nick: mysql-5.1.40sp1-release
            timestamp: Wed 2009-11-25 18:18:52 +0100
            message:
              Backport into build-200911241145-5.1.40sp1
              
              > ------------------------------------------------------------
              > revno: 3190 [merge]
              > revision-id: kostja@sun.com-20091103174552-bfpak6r7ngf5cbjb
              > parent: magnus.blaudd@sun.com-20091103170719-6b64sjnivsiyz6xy
              > parent: kostja@sun.com-20091103165854-7di545xruez8w207
              > committer: Konstantin Osipov <kostja@sun.com>
              > branch nick: 5.1-41756
              > timestamp: Tue 2009-11-03 20:45:52 +0300
              > message:
              >   A fix and a test case for 
              >   Bug#41756 "Strange error messages about locks from InnoDB".
              >         
              >   In JT_EQ_REF (join_read_key()) access method, 
              >   don't try to unlock rows in the handler, unless certain that 
              >   a) they were locked
              >   b) they are not used.
              >   
              >   Unlocking of rows is done by the logic of the nested join loop,
              >   and is unaware of the possible caching that the access method may
              >   have. This could lead to double unlocking, when a row
              >   was unlocked first after reading into the cache, and then 
              >   when taken from cache, as well as to unlocking of rows which
              >   were actually used (but taken from cache).
              >         
              >   Delegate part of the unlocking logic to the access method,
              >   and in JT_EQ_REF count how many times a record was actually 
              >   used in the join. Unlock it only if it's usage count is 0.
              >   
              >   Implemented review comments.
              > ------------------------------------------------------------
              > Use --include-merges or -n0 to see merged revisions.
            ------------------------------------------------------------
            revno: 3138.8.17
            committer: MySQL Build Team <build@mysql.com>
            branch nick: mysql-5.1.40sp1-release
            timestamp: Wed 2009-11-25 18:17:57 +0100
            message:
              Backport into build-200911241145-5.1.40sp1
              
              > ------------------------------------------------------------
              > revno: 3184.7.1
              > revision-id: luis.soares@sun.com-20091027151553-ri74b2zdchw8wyg7
              > parent: joro@sun.com-20091019135504-e6fmhf4xyy0wdymb
              > committer: Luis Soares <luis.soares@sun.com>
              > branch nick: mysql-5.1-bugteam
              > timestamp: Tue 2009-10-27 15:15:53 +0000
              > message:
              >   BUG#48297: Schema name is ignored when LOAD DATA is written into 
              >   binlog, replication aborts
              >   
              >   In SBR or MBR, the schema name is not being written to the binlog
              >   when executing a LOAD DATA statement. This becomes a problem when
              >   the current database (lets call it db1) is different from the
              >   table's schema (lets call it db2). For instance, take the
              >   following statements:
              >     
              >     use db1;
              >     load data local infile 'infile.txt' into table db2.t
              >   
              >   Should this statement be logged without t's schema (db2), when
              >   replaying it, one can get db1.t populated instead of db2.t (if
              >   db1.t exists). On the other hand, if there is no db1.t at all,
              >   replication will stop.
              >   
              >   We fix this by always logging the table (in load file) with fully
              >   qualified name when its schema is different from the current
              >   database or when no default database was selected.
            ------------------------------------------------------------
            revno: 3138.8.16
            committer: MySQL Build Team <build@mysql.com>
            branch nick: mysql-5.1.40sp1-release
            timestamp: Wed 2009-11-25 18:16:26 +0100
            message:
              Backport into build-200911241145-5.1.40sp1
              
              > ------------------------------------------------------------
              > revno: 3184.3.13
              > revision-id: joro@sun.com-20091019135504-e6fmhf4xyy0wdymb
              > parent: joro@sun.com-20091026095557-euhe1z9oxtgkw35h
              > committer: Georgi Kodinov <joro@sun.com>
              > branch nick: B47788-5.1-bugteam
              > timestamp: Mon 2009-10-19 16:55:04 +0300
              > message:
              >   Bug #47788: Crash in TABLE_LIST::hide_view_error on 
              >     UPDATE + VIEW + SP + MERGE + ALTER
              >   
              >   When cleaning up the stored procedure's internal 
              >   structures the flag to ignore the errors for 
              >   INSERT/UPDATE IGNORE was not cleaned up.
              >   As a result error ignoring was on during name 
              >   resolution. And this is an abnormal situation : the
              >   SELECT_LEX flag can be on only during query execution.
              >   
              >   Fixed by correctly cleaning up the SELECT_LEX flag 
              >   when reusing the SELECT_LEX in a second execution.
            ------------------------------------------------------------
            revno: 3138.8.15
            committer: MySQL Build Team <build@mysql.com>
            branch nick: mysql-5.1.40sp1-release
            timestamp: Wed 2009-11-25 18:14:34 +0100
            message:
              Backport into build-200911241145-5.1.40sp1
              
              > ------------------------------------------------------------
              > revno: 3182 [merge]
              > revision-id: ramil@mysql.com-20091018162655-z4dlolfx5s0zem8l
              > parent: alexey.kopytov@sun.com-20091016201951-fsht0wm8xn8vkzsx
              > parent: ramil@mysql.com-20091013044327-24km05wc060ied87
              > committer: Ramil Kalimullin <ramil@mysql.com>
              > branch nick: mysql-5.1-bugteam
              > timestamp: Sun 2009-10-18 21:26:55 +0500
              > message:
              >   Fix for bug#47963: Wrong results when index is used
              >   
              >   Problem: using null microsecond part in a WHERE condition 
              >   (e.g. WHERE date_time_field <= "YYYY-MM-DD HH:MM:SS.0000") 
              >   may lead to wrong results due to improper DATETIMEs 
              >   comparison in some cases.
              >   
              >   Fix: comparing DATETIMEs as strings we must trim trailing 0's
              >   in such cases.
              > ------------------------------------------------------------
              > Use --include-merges or -n0 to see merged revisions.
            ------------------------------------------------------------
            revno: 3138.8.14
            committer: MySQL Build Team <build@mysql.com>
            branch nick: mysql-5.1.40sp1-release
            timestamp: Wed 2009-11-25 18:11:54 +0100
            message:
              Backport into build-200911241145-5.1.40sp1
              
              > ------------------------------------------------------------
              > revno: 3181
              > revision-id: alexey.kopytov@sun.com-20091016201951-fsht0wm8xn8vkzsx
              > parent: joerg@mysql.com-20091016164025-kb4sbrggq5o7zufc
              > committer: Alexey Kopytov <Alexey.Kopytov@Sun.com>
              > branch nick: mysql-5.1-bugteam
              > timestamp: Sat 2009-10-17 00:19:51 +0400
              > message:
              >   Bug #47123: Endless 100% CPU loop with STRAIGHT_JOIN 
              >    
              >   The problem was in incorrect handling of predicates involving 
              >   NULL as a constant value by the range optimizer. 
              >    
              >   For example, when creating a SEL_ARG node from a condition of 
              >   the form "field < const" (which would normally result in the 
              >   "NULL < field < const" SEL_ARG),  the special case when "const" 
              >   is NULL was not taken into account, so "NULL < field < NULL" 
              >   was produced for the "field < NULL" condition. 
              >    
              >   As a result, SEL_ARG structures of this form could not be 
              >   further optimized which in turn could lead to incorrectly 
              >   constructed SEL_ARG trees. In particular, code assuming SEL_ARG 
              >   structures to always form a sequence of ordered disjoint 
              >   intervals could enter an infinite loop under some 
              >   circumstances. 
              >    
              >   Fixed by changing get_mm_leaf() so that for any sargable 
              >   predicate except "<=>" involving NULL as a constant, "empty" 
              >   SEL_ARG is returned, since such a predicate is always false. 
            ------------------------------------------------------------
            revno: 3138.8.13
            committer: MySQL Build Team <build@mysql.com>
            branch nick: mysql-5.1.40sp1-release
            timestamp: Wed 2009-11-25 18:09:30 +0100
            message:
              Backport into build-200911241145-5.1.40sp1
              
              > ------------------------------------------------------------
              > revno: 3148.9.6
              > revision-id: martin.hansson@sun.com-20091102122407-krzh4h0i052lbwr5
              > parent: davi.arnaut@sun.com-20091102112236-k3myix2xy8miyv4s
              > committer: Martin Hansson <martin.hansson@sun.com>
              > branch nick: 5.1bt
              > timestamp: Mon 2009-11-02 13:24:07 +0100
              > message:
              >   Bug#47925: regression of range optimizer and date comparison in 5.1.39!
              >   
              >   When a query was using a DATE or DATETIME value formatted
              >   using any other separator characters beside hyphen '-', a
              >   query with a greater-or-equal '>=' condition matching only
              >   the greatest value in an indexed column, the result was
              >   empty if index range scan was employed.
              >   
              >   The range optimizer got a new feature between 5.1.38 and
              >   5.1.39 that changes a greater-or-equal condition to a
              >   greater-than if the value matching that in the query was not
              >   present in the table. But the value comparison function
              >   compared the dates as strings instead of dates.
              >   
              >   The bug was fixed by splitting the function
              >   get_date_from_str in two: One part that parses and does
              >   error checking. This function is now visible outside the
              >   module. The old get_date_from_str now calls the new
              >   function.
            ------------------------------------------------------------
            revno: 3138.8.12
            committer: MySQL Build Team <build@mysql.com>
            branch nick: mysql-5.1.40sp1-release
            timestamp: Wed 2009-11-25 18:04:39 +0100
            message:
              Backport into build-200911241145-5.1.40sp1
              
              > ------------------------------------------------------------
              > revno: 3148.9.3
              > revision-id: azundris@mysql.com-20091029230154-jp2xqvzw2nhj9q41
              > parent: azundris@mysql.com-20091027095316-54lwjr9vqkscq1ik
              > committer: Tatiana A. Nurnberg <azundris@mysql.com>
              > branch nick: 51-48295
              > timestamp: Thu 2009-10-29 16:01:54 -0700
              > message:
              >   Bug#48295: explain extended crash with subquery and ONLY_FULL_GROUP_BY sql_mode
              >   
              >   If an outer query is broken, a subquery might not even get set up.
              >   EXPLAIN EXTENDED did not expect this and merrily tried to de-ref all
              >   of the half-setup info.
              >   
              >   We now catch this case and print as much as we have, as it doesn't cost us
              >   anything (doesn't make regular execution slower).
            ------------------------------------------------------------
            revno: 3138.8.11
            committer: MySQL Build Team <build@mysql.com>
            branch nick: mysql-5.1.40sp1-release
            timestamp: Wed 2009-11-25 18:00:46 +0100
            message:
              Backport into build-200911241145-5.1.40sp1
              
              > ------------------------------------------------------------
              > revno: 3148.8.5
              > revision-id: davi.arnaut@sun.com-20091102112139-pztthzy6qj8jzomn
              > parent: svoj@sun.com-20091103091902-vwszwwpfi1f4zrpn
              > committer: Davi Arnaut <Davi.Arnaut@Sun.COM>
              > branch nick: 48370-5.1
              > timestamp: Mon 2009-11-02 09:21:39 -0200
              > message:
              >   Bug#48370: Absolutely wrong calculations with GROUP BY and decimal fields when using IF
              >   Bug#45261: Crash, stored procedure + decimal
              >   
              >   Revert fix for Bug#45261 due to unforeseen bugs.
            ------------------------------------------------------------
            revno: 3138.8.10
            committer: MySQL Build Team <build@mysql.com>
            branch nick: mysql-5.1.40sp1-release
            timestamp: Wed 2009-11-25 17:58:51 +0100
            message:
              Backport into build-200911241145-5.1.40sp1
              
              > ------------------------------------------------------------
              > revno: 3148.13.4
              > revision-id: svoj@sun.com-20091102144320-0hz2ti21em510ee5
              > parent: svoj@sun.com-20091102144140-8de1z6mdy5dopw3j
              > committer: Sergey Vojtovich <svoj@sun.com>
              > branch nick: mysql-5.1-bugteam
              > timestamp: Mon 2009-11-02 18:43:20 +0400
              > message:
              >   Applying InnoDB snashot 5.1-ss6129
              >   
              >   Detailed revision comments:
              >   
              >   r6051 | sunny | 2009-10-12 07:05:00 +0300 (Mon, 12 Oct 2009) | 6 lines
              >   branches/5.1: Ignore negative values supplied by the user when calculating the
              >   next value to store in dict_table_t. Setting autoincrement columns top negative
              >   values is undefined behavior and this change should bring the behavior of
              >   InnoDB closer to what users expect. Added several tests to check.
              >   rb://162
            ------------------------------------------------------------
            revno: 3138.8.9
            committer: MySQL Build Team <build@mysql.com>
            branch nick: mysql-5.1.40sp1-release
            timestamp: Wed 2009-11-25 17:56:33 +0100
            message:
              Backport into build-200911241145-5.1.40sp1
              
              > ------------------------------------------------------------
              > revno: 3148.13.3
              > revision-id: svoj@sun.com-20091102144140-8de1z6mdy5dopw3j
              > parent: svoj@sun.com-20091102143655-lo69f57p82nky58q
              > committer: Sergey Vojtovich <svoj@sun.com>
              > branch nick: mysql-5.1-bugteam
              > timestamp: Mon 2009-11-02 18:41:40 +0400
              > message:
              >   Applying InnoDB snashot 5.1-ss6129
              >   
              >   Detailed revision comments:
              >   
              >   r6045 | jyang | 2009-10-08 02:27:08 +0300 (Thu, 08 Oct 2009) | 7 lines
              >   branches/5.1: Fix bug #47777. Treat the Geometry data same as
              >   Binary BLOB in ha_innobase::store_key_val_for_row(), since the
              >   Geometry data is stored as Binary BLOB in Innodb.
              >   
              >   Review: rb://180 approved by Marko Makela.
            ------------------------------------------------------------
            revno: 3138.8.8
            committer: MySQL Build Team <build@mysql.com>
            branch nick: mysql-5.1.40sp1-release
            timestamp: Wed 2009-11-25 17:52:26 +0100
            message:
              Backport into build-200911241145-5.1.40sp1
              
              > ------------------------------------------------------------
              > revno: 1810.3961.7
              > committer: Georgi Kodinov <joro@sun.com>
              > branch nick: B48291-5.0-bugteam
              > timestamp: Fri 2009-10-30 15:15:43 +0200
              > message:
              >   Bug #48291 : crash with row() operator,select into @var, and
              >     subquery returning multiple rows
              >
              >   Error handling was missing when handling subqueires in WHERE
              >   and when assigning a SELECT result to a @variable.
              >   This caused crash(es).
              >
              >   Fixed by adding error handling code to both the WHERE
              >   condition evaluation and to assignment to an @variable.
              > ------------------------------------------------------------
            ------------------------------------------------------------
            revno: 3138.8.7
            committer: MySQL Build Team <build@mysql.com>
            branch nick: mysql-5.1.40sp1-release
            timestamp: Wed 2009-11-25 17:45:33 +0100
            message:
              Backport into build-200911241145-5.1.40sp1
              
              > ------------------------------------------------------------
              > revno: 1810.3964.1
              > revision-id: alexey.kopytov@sun.com-20091030155453-0vlfwki805h9os62
              > parent: joerg@mysql.com-20091016122941-rf6z0keqvmlgjfto
              > committer: Alexey Kopytov <Alexey.Kopytov@Sun.com>
              > branch nick: my50-bug48131
              > timestamp: Fri 2009-10-30 18:54:53 +0300
              > message:
              >   Bug #48131: crash group by with rollup, distinct, filesort,
              >               with temporary tables
              >   
              >   There were two problems the test case from this bug was
              >   triggering:
              >   
              >   1. JOIN::rollup_init() was supposed to wrap all constant Items
              >   into another object for queries with the WITH ROLLUP modifier
              >   to ensure they are never considered as constants and therefore
              >   are written into temporary tables if the optimizer chooses to
              >   employ them for DISTINCT/GROUP BY handling.
              >   
              >   However, JOIN::rollup_init() was called before
              >   make_join_statistics(), so Items corresponding to fields in
              >   const tables could not be handled as intended, which was
              >   causing all kinds of problems later in the query execution. In
              >   particular, create_tmp_table() assumed all constant items
              >   except "hidden" ones to be removed earlier by remove_const()
              >   which led to improperly initialized Field objects for the
              >   temporary table being created. This is what was causing crashes
              >   and valgrind errors in storage engines.
              >   
              >   2. Even when the above problem had been fixed, the query from
              >   the test case produced incorrect results due to some
              >   DISTINCT/GROUP BY optimizations being performed by the
              >   optimizer that are inapplicable in the WITH ROLLUP case.
              >   
              >   Fixed by disabling inapplicable DISTINCT/GROUP BY optimizations
              >   when the WITH ROLLUP modifier is present, and splitting the
              >   const-wrapping part of JOIN::rollup_init() into a separate
              >   method which is now invoked after make_join_statistics() when
              >   the const tables are already known.
            ------------------------------------------------------------
            revno: 3138.8.6
            committer: MySQL Build Team <build@mysql.com>
            branch nick: mysql-5.1.40sp1-release
            timestamp: Wed 2009-11-25 17:43:47 +0100
            message:
              Backport into build-200911241145-5.1.40sp1
              
              > ------------------------------------------------------------
              > revno: 1810.3961.6
              > revision-id: joro@sun.com-20091030094044-quadg0bwjy7cwqzw
              > parent: joro@sun.com-20091029152429-ks55fhrp4lhknyij
              > committer: Georgi Kodinov <joro@sun.com>
              > branch nick: B48293-5.0-bugteam
              > timestamp: Fri 2009-10-30 11:40:44 +0200
              > message:
              >   Bug #48293: crash with procedure analyse, view with > 10 columns,
              >   having clause...
              >   
              >   The fix for bug 46184 was not very complete. It was not covering
              >   views using temporary tables and multiple tables in a FROM clause.
              >   Fixed by reverting the fix for 46184 and making a more general
              >   check that is checking at the right execution stage and for all
              >   of the non-supported cases.
              >   Now PROCEDURE ANALYZE on non-top level SELECT is also forbidden.
              >   Updated the analyse.test and subselect.test accordingly.
            ------------------------------------------------------------
            revno: 3138.8.5
            committer: MySQL Build Team <build@mysql.com>
            branch nick: mysql-5.1.40sp1-release
            timestamp: Wed 2009-11-25 17:42:10 +0100
            message:
              Backport into build-200911241145-5.1.40sp1
              
              > ------------------------------------------------------------
              > revno: 1810.3961.12
              > revision-id: li-bing.song@sun.com-20091103090041-zj7nedx6ok5jgges
              > parent: davi.arnaut@sun.com-20091102201021-1brn7cjb1kvqg9gr
              > committer: <Li-Bing.Song@sun.com>
              > branch nick: mysql-5.0-bugteam
              > timestamp: Tue 2009-11-03 17:00:41 +0800
              > message:
              >   BUG#48216 Replication fails on all slaves after upgrade to 5.0.86 on master
              >   
              >   When a sessione is closed, all temporary tables of the session are automatically 
              >   dropped and are binlogged. But it will be binlogged with wrong database names when
              >   the length of the temporary tables' database names are greater than the 
              >   length of the current database name or the current database is not set.
              >   
              >   Query_log_event's db_len is forgot to set when Query_log_event's db is set.
              >   This patch wrote code to set db_len immediately after db has set.
            ------------------------------------------------------------
            revno: 3138.8.4
            committer: MySQL Build Team <build@mysql.com>
            branch nick: mysql-5.1.40sp1-release
            timestamp: Wed 2009-11-25 17:36:58 +0100
            message:
              Backport into build-200911241145-5.1.40sp1
              
              > ------------------------------------------------------------
              > revno: 1810.3959.6
              > revision-id: joro@sun.com-20091021084345-iki6z0uceieoupey
              > parent: ramil@mysql.com-20091023112648-gie6o3odj57cxh1e
              > committer: Georgi Kodinov <joro@sun.com>
              > branch nick: B47780-5.0-bugteam
              > timestamp: Wed 2009-10-21 11:43:45 +0300
              > message:
              >   Bug #47780: crash when comparing GIS items from subquery
              >         
              >   If the first argument to GeomFromWKB function is a geometry
              >   field then the function just returns its value.
              >   However in doing so it's not preserving first argument's 
              >   null_value flag and this causes unexpected null value to
              >   be returned to the calling function.
              >         
              >   Fixed by updating the null_value of the GeomFromWKB function
              >   in such cases (and all other cases that return a NULL e.g.
              >   because of not enough memory for the return buffer).
            ------------------------------------------------------------
            revno: 3138.8.3
            committer: MySQL Build Team <build@mysql.com>
            branch nick: mysql-5.1.40sp1-release
            timestamp: Wed 2009-11-25 17:35:05 +0100
            message:
              Backport into build-200911241145-5.1.40sp1
              
              > ------------------------------------------------------------
              > revno: 1810.3959.5
              > revision-id: ramil@mysql.com-20091023112648-gie6o3odj57cxh1e
              > parent: ramil@mysql.com-20091021090408-208mvwwrcroi2j8c
              > committer: Ramil Kalimullin <ramil@mysql.com>
              > branch nick: b48258-5.0-bugteam
              > timestamp: Fri 2009-10-23 16:26:48 +0500
              > message:
              >   Fix for bug#48258: Assertion failed when using a spatial index
              >   
              >   Problem: involving a spatial index for "non-spatial" queries
              >   (that don't containt MBRXXX() functions) may lead to failed assert.
              >   
              >   Fix: don't use spatial indexes in such cases.
            ------------------------------------------------------------
            revno: 3138.8.2
            committer: MySQL Build Team <build@mysql.com>
            branch nick: mysql-5.1.40sp1-release
            timestamp: Wed 2009-11-25 17:32:04 +0100
            message:
              Backport into build-200911241145-5.1.40sp1
              
              > ------------------------------------------------------------
              > revno: 1810.3959.4
              > revision-id: ramil@mysql.com-20091021090408-208mvwwrcroi2j8c
              > parent: azundris@mysql.com-20091021033856-ydodp4q42o58e7ka
              > committer: Ramil Kalimullin <ramil@mysql.com>
              > branch nick: b47019-5.0-bugteam
              > timestamp: Wed 2009-10-21 14:04:08 +0500
              > message:
              >   Fix for bug#47019: Assertion failed: 0, file .\rt_mbr.c, 
              >   line 138 when forcing a spatial index
              >   
              >   Problem: "Spatial indexes can be involved in the search 
              >   for queries that use a function such as MBRContains() 
              >   or MBRWithin() in the WHERE clause".
              >   Using spatial indexes for JOINs with =, <=> etc.
              >   predicates is incorrect.
              >   
              >   Fix: disable spatial indexes for such queries.
            ------------------------------------------------------------
            revno: 3138.8.1
            committer: Kent Boortz <Kent.Boortz@Sun.COM>
            branch nick: mysql-5.1.40sp1-release
            timestamp: Wed 2009-11-25 13:23:25 +0100
            message:
              Set version number for mysql-5.1.40sp1 release
        ------------------------------------------------------------
        revno: 3236.1.3
        author: karen.langford@sun.com
        committer: MySQL Build Team <build@mysql.com>
        branch nick: mysql-5.1
        timestamp: Wed 2009-12-02 18:52:19 +0100
        message:
          Raise version number after cloning 5.1.42
