1. 24 Jun, 2009 7 commits
    • MySQL Build Team's avatar
      Backport into build-200906240007-5.1.34sp1 · fab67c98
      MySQL Build Team authored
      > ------------------------------------------------------------
      > 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.
      fab67c98
    • MySQL Build Team's avatar
      Backport into build-200906240007-5.1.34sp1 · 0837b591
      MySQL Build Team authored
      > ------------------------------------------------------------
      > 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.
      0837b591
    • MySQL Build Team's avatar
      Backport into build-200906240007-5.1.34sp1 · e82378ac
      MySQL Build Team authored
      > ------------------------------------------------------------
      > 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.
      e82378ac
    • MySQL Build Team's avatar
      Backport into build-200906240007-5.1.34sp1 · b917b39d
      MySQL Build Team authored
      > ------------------------------------------------------------
      > 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.
      b917b39d
    • MySQL Build Team's avatar
      Backport into build-200906240007-5.1.34sp1 · c6fdd918
      MySQL Build Team authored
      > ------------------------------------------------------------
      > 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.
      c6fdd918
    • MySQL Build Team's avatar
      Backport into mysql-5.1.34sp1-release · 0bc567d0
      MySQL Build Team authored
      > ------------------------------------------------------------
      > 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.
      0bc567d0
    • MySQL Build Team's avatar
      Backport into mysql-5.1.34sp1-release · e4e5c649
      MySQL Build Team authored
      > ------------------------------------------------------------
      > 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
      e4e5c649
  2. 02 Apr, 2009 1 commit
  3. 01 Apr, 2009 1 commit
  4. 31 Mar, 2009 1 commit
  5. 27 Mar, 2009 9 commits
  6. 26 Mar, 2009 5 commits
  7. 25 Mar, 2009 13 commits
  8. 24 Mar, 2009 3 commits