1. 29 May, 2007 6 commits
  2. 28 May, 2007 6 commits
    • thek@adventure.(none)'s avatar
      Merge kpettersson@bk-internal.mysql.com:/home/bk/mysql-5.1-runtime · bdd52a6e
      thek@adventure.(none) authored
      into  adventure.(none):/home/thek/Development/cpp/mysql-5.1-runtime
      bdd52a6e
    • thek@adventure.(none)'s avatar
    • kostja@vajra.(none)'s avatar
      Fix a compile-time warning. · 568bf9e3
      kostja@vajra.(none) authored
      568bf9e3
    • thek@adventure.(none)'s avatar
      Bug#24988 FLUSH PRIVILEGES causes brief unavailability · 4ec0f6ce
      thek@adventure.(none) authored
      - A race condition caused brief unavailablility when trying to acccess
        a table.
      - The unprotected variable 'grant_option' wasn't intended to alternate
        during normal execution. Variable initialization moved to grant_init
        a lines responsible for the alternation are removed. 
      4ec0f6ce
    • kostja@vajra.(none)'s avatar
      Merge bk-internal.mysql.com:/home/bk/mysql-5.1-runtime · e0571ebb
      kostja@vajra.(none) authored
      into  vajra.(none):/opt/local/work/mysql-5.1-4968-clean
      e0571ebb
    • kostja@vajra.(none)'s avatar
      5.1 version of a fix and test cases for bugs: · c7594877
      kostja@vajra.(none) authored
      Bug#4968 ""Stored procedure crash if cursor opened on altered table"
      Bug#6895 "Prepared Statements: ALTER TABLE DROP COLUMN does nothing"
      Bug#19182 "CREATE TABLE bar (m INT) SELECT n FROM foo; doesn't work from 
      stored procedure."
      Bug#19733 "Repeated alter, or repeated create/drop, fails"
      Bug#22060 "ALTER TABLE x AUTO_INCREMENT=y in SP crashes server"
      Bug#24879 "Prepared Statements: CREATE TABLE (UTF8 KEY) produces a 
      growing key length" (this bug is not fixed in 5.0)
      
      Re-execution of CREATE DATABASE, CREATE TABLE and ALTER TABLE 
      statements in stored routines or as prepared statements caused
      incorrect results (and crashes in versions prior to 5.0.25).
      
      In 5.1 the problem occured only for CREATE DATABASE, CREATE TABLE
      SELECT and CREATE TABLE with INDEX/DATA DIRECTOY options).
        
      The problem of bugs 4968, 19733, 19282 and 6895 was that functions
      mysql_prepare_table, mysql_create_table and mysql_alter_table are not
      re-execution friendly: during their operation they modify contents
      of LEX (members create_info, alter_info, key_list, create_list),
      thus making the LEX unusable for the next execution.
      In particular, these functions removed processed columns and keys from
      create_list, key_list and drop_list. Search the code in sql_table.cc 
      for drop_it.remove() and similar patterns to find evidence.
        
      The fix is to supply to these functions a usable copy of each of the
      above structures at every re-execution of an SQL statement. 
        
      To simplify memory management, LEX::key_list and LEX::create_list
      were added to LEX::alter_info, a fresh copy of which is created for
      every execution.
        
      The problem of crashing bug 22060 stemmed from the fact that the above 
      metnioned functions were not only modifying HA_CREATE_INFO structure 
      in LEX, but also were changing it to point to areas in volatile memory
      of the execution memory root.
         
      The patch solves this problem by creating and using an on-stack
      copy of HA_CREATE_INFO in mysql_execute_command.
      
      Additionally, this patch splits the part of mysql_alter_table
      that analizes and rewrites information from the parser into
      a separate function - mysql_prepare_alter_table, in analogy with
      mysql_prepare_table, which is renamed to mysql_prepare_create_table.
      c7594877
  3. 26 May, 2007 1 commit
    • andrey@whirlpool.mysql.com's avatar
      Fix for · a0489dbf
      andrey@whirlpool.mysql.com authored
      bug#26338 events_bugs.test fail on Debian
      and
      bug#28285 Test "events_bugs" has instable results of "select /*1*/ ... from processlist"
      a0489dbf
  4. 25 May, 2007 5 commits
    • malff/marcsql@weblab.(none)'s avatar
      Code review comments · 0bb9b8f9
      malff/marcsql@weblab.(none) authored
      0bb9b8f9
    • malff/marcsql@weblab.(none)'s avatar
      Bug#27876 (SF with cyrillic variable name fails during execution (regression)) · 88e3abf5
      malff/marcsql@weblab.(none) authored
      The root cause of this bug is related to the function skip_rear_comments,
      in sql_lex.cc
      
      Recent code changes in skip_rear_comments changed the prototype from
      "const uchar*" to "const char*", which had an unforseen impact on this test:
        (endp[-1] < ' ')
      With unsigned characters, this code filters bytes of value [0x00 - 0x20]
      With *signed* characters, this also filters bytes of value [0x80 - 0xFF].
      
      This caused the regression reported, considering cyrillic characters in the
      parameter name to be whitespace, and truncated.
      Note that the regression is present both in 5.0 and 5.1.
      
      With this fix:
      - [0x80 - 0xFF] bytes are no longer considered whitespace.
      This alone fixes the regression.
      
      In addition, filtering [0x00 - 0x20] was found bogus and abusive,
      so that the code now filters uses my_isspace when looking for whitespace.
      
      Note that this fix is only addressing the regression affecting UTF-8
      in general, but does not address a more fundamental problem with
      skip_rear_comments: parsing a string *backwards*, starting at end[-1],
      is not safe with multi-bytes characters, so that end[-1] can confuse the
      last byte of a multi-byte characters with a characters to filter out.
      
      The only known impact of this remaining issue affects objects that have to
      meet all the conditions below:
      
      - the object is a FUNCTION / PROCEDURE / TRIGGER / EVENT / VIEW
      - the body consist of only *1* instruction, and does *not* contain a
        BEGIN-END block
      - the instruction ends, lexically, with <ident> <whitespace>* ';'?
        For example, "select <ident>;" or "return <ident>;"
      - The last character of <ident> is a multi-byte character
      - the last byte of this character is ';' '*', '/' or whitespace
      
      In this case, the body of the object will be truncated after parsing,
      and stored in an invalid format.
      
      This last issue has not been fixed in this patch, since the real fix
      will be implemented by Bug 25411 (trigger code truncated), which is caused
      by the very same code.
      The real problem is that the function skip_rear_comments is only a
      work-around, and should be removed entirely: see the proposed patch for
      bug 25411 for details.
      88e3abf5
    • andrey@whirlpool.mysql.com's avatar
      Merge ahristov@bk-internal.mysql.com:/home/bk/mysql-5.1-runtime · 61276df0
      andrey@whirlpool.mysql.com authored
      into  whirlpool.mysql.com:/work/mysql-5.1-runtime
      61276df0
    • andrey@whirlpool.mysql.com's avatar
      Fix for bug#28666 CREATE EVENT ... EVERY 0 SECOND let server crash · 47c0c5a0
      andrey@whirlpool.mysql.com authored
      A missing check for zero value of interval was added.
      47c0c5a0
    • mleich@four.local.lan's avatar
      Merge four.local.lan:/WORK/mysql-5.1-runtime/src-clean · 50c30caf
      mleich@four.local.lan authored
      into  four.local.lan:/WORK/mysql-5.1-runtime/src-1
      50c30caf
  5. 24 May, 2007 17 commits
  6. 23 May, 2007 5 commits
    • dlenev@mockturtle.local's avatar
      Merge mockturtle.local:/home/dlenev/src/mysql-5.0-like · 661aaec6
      dlenev@mockturtle.local authored
      into  mockturtle.local:/home/dlenev/src/mysql-5.1-like-2
      661aaec6
    • dlenev@mockturtle.local's avatar
      Merge bk-internal.mysql.com:/home/bk/mysql-5.1-runtime · 2b3ae933
      dlenev@mockturtle.local authored
      into  mockturtle.local:/home/dlenev/src/mysql-5.1-like-2
      2b3ae933
    • dlenev@mockturtle.local's avatar
      5.1 version of fix for: · 8e8f4c05
      dlenev@mockturtle.local authored
        Bug #23667 "CREATE TABLE LIKE is not isolated from alteration
                    by other connections"
        Bug #18950 "CREATE TABLE LIKE does not obtain LOCK_open"
      As well as:
        Bug #25578 "CREATE TABLE LIKE does not require any privileges
                    on source table".
      
      The first and the second bugs resulted in various errors and wrong
      binary log order when one tried to execute concurrently CREATE TABLE LIKE
      statement and DDL statements on source table or DML/DDL statements on its
      target table.
      
      The problem was caused by incomplete protection/table-locking against
      concurrent statements implemented in mysql_create_like_table() routine.
      We solve it by simply implementing such protection in proper way.
      Most of actual work for 5.1 was already done by fix for bug 20662 and
      preliminary patch changing locking in ALTER TABLE.
      
      The third bug allowed user who didn't have any privileges on table create
      its copy and therefore circumvent privilege check for SHOW CREATE TABLE.
      
      This patch solves this problem by adding privilege check, which was missing.
      
      Finally it also removes some duplicated code from mysql_create_like_table()
      and thus fixes bug #26869 "TABLE_LIST::table_name_length inconsistent with
      TABLE_LIST::table_name".
      8e8f4c05
    • dlenev@mockturtle.local's avatar
      5.0 version of fix for: · c07b3670
      dlenev@mockturtle.local authored
       Bug #23667 "CREATE TABLE LIKE is not isolated from alteration
                   by other connections"
       Bug #18950 "CREATE TABLE LIKE does not obtain LOCK_open"
      As well as:
       Bug #25578 "CREATE TABLE LIKE does not require any privileges
                   on source table".
      
      The first and the second bugs resulted in various errors and wrong
      binary log order when one tried to execute concurrently CREATE TABLE LIKE
      statement and DDL statements on source table or DML/DDL statements on its
      target table.
      
      The problem was caused by incomplete protection/table-locking against
      concurrent statements implemented in mysql_create_like_table() routine.
      We solve it by simply implementing such protection in proper way (see
      comment for sql_table.cc for details).
      
      The third bug allowed user who didn't have any privileges on table create
      its copy and therefore circumvent privilege check for SHOW CREATE TABLE.
      
      This patch solves this problem by adding privilege check, which was missing.
      
      Finally it also removes some duplicated code from mysql_create_like_table().
      
      Note that, altough tests covering concurrency-related aspects of CREATE TABLE
      LIKE behaviour will only be introduced in 5.1, they were run manually for
      this patch as well.
      c07b3670
    • thek@adventure.(none)'s avatar
      f52c5a20