1. 29 May, 2007 1 commit
  2. 28 May, 2007 1 commit
    • 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
  3. 25 May, 2007 2 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
  4. 24 May, 2007 1 commit
  5. 23 May, 2007 4 commits
    • 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
    • svoj@june.mysql.com's avatar
      Merge mysql.com:/home/svoj/devel/mysql/merge/mysql-4.1-engines · 43b2dc18
      svoj@june.mysql.com authored
      into  mysql.com:/home/svoj/devel/mysql/merge/mysql-5.0-engines
      43b2dc18
    • svoj@mysql.com/june.mysql.com's avatar
      Merge mysql.com:/home/svoj/devel/bk/mysql-5.0 · 122167bb
      svoj@mysql.com/june.mysql.com authored
      into  mysql.com:/home/svoj/devel/mysql/merge/mysql-5.0-engines
      122167bb
    • svoj@mysql.com/june.mysql.com's avatar
      Merge mysql.com:/home/svoj/devel/bk/mysql-4.1 · a4ddc226
      svoj@mysql.com/june.mysql.com authored
      into  mysql.com:/home/svoj/devel/mysql/merge/mysql-4.1-engines
      a4ddc226
  6. 22 May, 2007 3 commits
  7. 21 May, 2007 6 commits
  8. 19 May, 2007 2 commits
  9. 18 May, 2007 20 commits