1. 30 Aug, 2007 10 commits
  2. 29 Aug, 2007 7 commits
    • malff/marcsql@weblab.(none)'s avatar
      Manual merge · 496eb569
      malff/marcsql@weblab.(none) authored
      496eb569
    • malff/marcsql@weblab.(none)'s avatar
      Merge weblab.(none):/home/marcsql/TREE/mysql-5.0-runtime · 180ca238
      malff/marcsql@weblab.(none) authored
      into  weblab.(none):/home/marcsql/TREE/mysql-5.1-rt50-merge
      180ca238
    • davi@moksha.local's avatar
      Post-merge fixes for Bug#30632 · a2a5104d
      davi@moksha.local authored
      a2a5104d
    • davi@moksha.local's avatar
      Merge moksha.local:/Users/davi/mysql/push/bugs/old/30632-5.0 · 68047f7f
      davi@moksha.local authored
      into  moksha.local:/Users/davi/mysql/push/bugs/30632-5.1
      68047f7f
    • malff/marcsql@weblab.(none)'s avatar
      Bug#28779 (mysql_query() allows execution of statements with unbalanced · 6f72d990
      malff/marcsql@weblab.(none) authored
      comments)
      
      Before this fix, the server would accept queries that contained comments,
      even when the comments were not properly closed with a '*' '/' marker.
      
      For example,
        select 1 /* + 2 <EOF>
      would be accepted as
        select 1 /* + 2 */ <EOF>
      and executed as
        select 1
      
      With this fix, the server now rejects queries with unclosed comments
      as syntax errors.
      Both regular comments ('/' '*') and special comments ('/' '*' '!') must be
      closed with '*' '/' to be parsed correctly.
      6f72d990
    • davi@moksha.local's avatar
      Bug#21975 Grant and revoke statements are non-transactional · cb7486b4
      davi@moksha.local authored
      Bug#21422 GRANT/REVOKE possible inside stored function, probably in a trigger
      Bug#17244 GRANT gives strange error message when used in a stored function
      
      GRANT/REVOKE statements are non-transactional (no explicit transaction
      boundaries) in nature and hence are forbidden inside stored functions and
      triggers, but they weren't being effectively forbidden. Furthermore, the
      absence of implict commits makes changes made by GRANT/REVOKE statements to
      not be rolled back.
      
      The implemented fix is to issue a implicit commit with every GRANT/REVOKE
      statement, effectively prohibiting these statements in stored functions
      and triggers. The implicit commit also fixes the replication bug, and looks
      like being in concert with the behavior of DDL and administrative statements.
      
      Since this is a incompatible change, the following sentence should be
      added to the Manual in the very end of the 3rd paragraph, subclause
      13.4.3 "Statements That Cause an Implicit Commit": "Beginning with
      MySQL 5.0.??, the GRANT and REVOKE statements cause an implicit commit."
      
      Patch contributed by Vladimir Shebordaev
      cb7486b4
    • anozdrin/alik@ibm.'s avatar
      Test case for Bug#13675: DATETIME/DATE type in store proc param · 290d7249
      anozdrin/alik@ibm. authored
      seems to be converted as varbinary.
      
      The bug has been already fixed. This CS just adds a test case for it.
      290d7249
  3. 28 Aug, 2007 5 commits
  4. 27 Aug, 2007 4 commits
    • davi@moksha.local's avatar
      Bug#30632 HANDLER read failure causes hang · 77d78a88
      davi@moksha.local authored
      If, after the tables are locked, one of the conditions to read from a
      HANDLER table is not met, the handler code wrongly jumps to a error path
      that won't unlock the tables.
      
      The user-visible effect is that after a error in a handler read command,
      all subsequent handler operations on the same table will hang.
      
      The fix is simply to correct the code to jump to the (same) error path that
      unlocks the tables.
      77d78a88
    • davi@moksha.local's avatar
      Merge moksha.local:/Users/davi/mysql/push/mysql-5.1-runtime · 04847406
      davi@moksha.local authored
      into  moksha.local:/Users/davi/mysql/push/bugs/29936-5.1
      04847406
    • davi@moksha.local's avatar
      Merge moksha.local:/Users/davi/mysql/push/bugs/25164-5.0 · 769cd00e
      davi@moksha.local authored
      into  moksha.local:/Users/davi/mysql/push/bugs/25164-5.1
      769cd00e
    • davi@moksha.local's avatar
      Bug#25164 create table `a` as select * from `A` hangs · 91e1cc21
      davi@moksha.local authored
      The problem from a user's perspective: user creates table A, and then tries
      to CREATE TABLE a SELECT from A - and this causes a deadlock error, a hang,
      or fails with a debug assert, but only if the storage engine is InnoDB.
      
      The origin of the problem: InnoDB uses case-insensitive collation
      (system_charset_info) when looking up the internal table share, thus returning
      the same share for 'a' and 'A'.
      
      Cause of the user-visible behavior: since the same share is returned to SQL
      locking subsystem, it assumes that the same table is first locked (within the
      same session) for WRITE, and then for READ, and returns a deadlock error.
      However, the code is wrong in not properly cleaning up upon an error, leaving
      external locks in place, which leads to assertion failures and hangs.
      
      Fix that has been implemented: the SQL layer should properly propagate the
      deadlock error, cleaning up and freeing all resources.
      
      Further work towards a more complete solution: InnoDB should not use case
      insensitive collation for table share hash if table names on disk honor the case.
      91e1cc21
  5. 24 Aug, 2007 4 commits
  6. 23 Aug, 2007 3 commits
  7. 22 Aug, 2007 7 commits