1. 30 Aug, 2007 7 commits
    • unknown's avatar
      Merge weblab.(none):/home/marcsql/TREE/mysql-5.0-runtime · db56cb5b
      unknown authored
      into  weblab.(none):/home/marcsql/TREE/mysql-5.1-rt50-merge
      
      
      mysql-test/r/comments.result:
        failed auto merge
      mysql-test/t/comments.test:
        failed auto merge
      sql/sql_lex.cc:
        failed auto merge
      db56cb5b
    • unknown's avatar
      Merge malff@bk-internal.mysql.com:/home/bk/mysql-5.0-runtime · 672c421b
      unknown authored
      into  weblab.(none):/home/marcsql/TREE/mysql-5.0-28779-b
      
      
      672c421b
    • unknown's avatar
      Cleanup-patch for BUG#25843: changing default database between · 3edb6301
      unknown authored
      PREPARE and EXECUTE of statement breaks binlog.
      
      
      sql/sp.cc:
        - Polishing sp_use_new_db():
          - renamed no_access_check to force_switch to be more adequate;
          - fixed comment;
      sql/sql_class.h:
        Polishing: fixed comment.
      sql/sql_db.cc:
        1. Use mysql_change_db_impl() to reset current database instead of
        THD::set_db() in mysql_rm_db(). THD::set_db() does not take care of
        THD::db_access and database attributes (@@collation_database).
        2. Polishing: add, fix comments.
      3edb6301
    • unknown's avatar
      Merge polly.(none):/home/kaa/src/bug30164/my50-bug30164 · ffd0c6c1
      unknown authored
      into  polly.(none):/home/kaa/src/bug30164/my51-bug30164
      
      
      mysql-test/t/mysql.test:
        Auto merged
      ffd0c6c1
    • unknown's avatar
      Use double quotes instead of single ones which make the test fail on Windows.... · aef135da
      unknown authored
      Use double quotes instead of single ones which make the test fail on Windows. This is for bug #30164.
      
      
      mysql-test/t/mysql.test:
        Use double quotes instead of single ones which make the test fail on Windows.
      aef135da
    • unknown's avatar
      Merge polly.(none):/home/kaa/src/bug30164/my50-bug30164 · 88eb61b5
      unknown authored
      into  polly.(none):/home/kaa/src/bug30164/my51-bug30164
      
      
      client/mysql.cc:
        Auto merged
      mysql-test/r/mysql.result:
        Auto merged
      mysql-test/t/mysql.test:
        Auto merged
      88eb61b5
    • unknown's avatar
      Bug #30164: Using client side macro inside server side comments generates broken queries · bb986a24
      unknown authored
        
      Problem:
        
      In cases when a client-side macro appears inside a server-side comment, the add_line() function in mysql.cc discarded all characters until the next delimiter to remove macro arguments from the query string. This resulted in broken queries being sent to the server when the next delimiter character appeared past the comment's boundaries, because the comment closing sequence ('*/') was discarded.
        
      Fix:
        
      If a client-side macro appears inside a server-side comment, discard all characters in the comment after the macro (that is, until the end of the comment rather than the next delimiter).
      This is a minimal fix to allow only simple cases used by the mysqlbinlog utility. Limitations that are worth documenting:
        
      - Nested server-side and/or client-side comments are not supported by mysql.cc
      - Using client-side macros in multi-line server-side comments is not supported
      - All characters after a client-side macro in a server-side comment will be omitted from the query string (and thus, will not be sent to server).
      
      
      client/mysql.cc:
        If a client-side macro appears inside a server-side comment, discard all characters in the comment after the macro.
      mysql-test/r/mysql.result:
        Added a test case for bug #30164.
      mysql-test/t/mysql.test:
        Added a test case for bug #30164.
      bb986a24
  2. 29 Aug, 2007 7 commits
    • unknown's avatar
      Manual merge · 85ebacfa
      unknown authored
      85ebacfa
    • unknown's avatar
      Merge weblab.(none):/home/marcsql/TREE/mysql-5.0-runtime · 41afae51
      unknown authored
      into  weblab.(none):/home/marcsql/TREE/mysql-5.1-rt50-merge
      
      
      mysql-test/r/sp.result:
        failed auto merge
      mysql-test/t/sp.test:
        failed auto merge
      41afae51
    • unknown's avatar
      Post-merge fixes for Bug#30632 · bad0b628
      unknown authored
      
      mysql-test/r/handler_innodb.result:
        Post-merge: add Bug#30632 test case result
      mysql-test/r/handler_myisam.result:
        Post-merge fix of error number
      bad0b628
    • unknown's avatar
      Merge moksha.local:/Users/davi/mysql/push/bugs/old/30632-5.0 · 30678bc0
      unknown authored
      into  moksha.local:/Users/davi/mysql/push/bugs/30632-5.1
      
      
      sql/sql_handler.cc:
        Auto merged
      mysql-test/include/handler.inc:
        Auto merged
      mysql-test/r/handler_myisam.result:
        Auto merged
      30678bc0
    • unknown's avatar
      Bug#28779 (mysql_query() allows execution of statements with unbalanced · b0f899e9
      unknown 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.
      
      
      mysql-test/r/comments.result:
        Unbalanced comments are a syntax error.
      mysql-test/t/comments.test:
        Unbalanced comments are a syntax error.
      sql/sql_lex.cc:
        Unbalanced comments are a syntax error.
      b0f899e9
    • unknown's avatar
      Bug#21975 Grant and revoke statements are non-transactional · 26aadd21
      unknown 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
      
      
      mysql-test/r/sp-error.result:
        Test case result for Bug#17244
      mysql-test/t/sp-error.test:
        Test case for Bug#17244
      sql/sp_head.cc:
        Set that a procedure with GRANT/REVOKE command has a (implicit or explicit)
        commit.
      sql/sql_parse.cc:
        End active transaction in SQLCOM_GRANT and SQLCOM_REVOKE, and thus effectively
        prohibit these statements in stored functions and triggers. An implicit commit
        also fixes a bug in replication, when GRANT or REVOKE would disappear from the
        binary log in case of a subsequent ROLLBACK, since they were considered
        transactional statements.
      mysql-test/suite/rpl/r/rpl_binlog_grant.result:
        Add test case result for Bug#21975
      mysql-test/suite/rpl/t/rpl_binlog_grant.test:
        Add test case for Bug#21975
      26aadd21
    • unknown's avatar
      Test case for Bug#13675: DATETIME/DATE type in store proc param · 3d544050
      unknown authored
      seems to be converted as varbinary.
      
      The bug has been already fixed. This CS just adds a test case for it.
      
      
      mysql-test/r/sp.result:
        Update result file.
      mysql-test/t/sp.test:
        Test case for BUG#13675.
      3d544050
  3. 28 Aug, 2007 5 commits
    • unknown's avatar
      Manual merge · 0ecee6df
      unknown authored
      0ecee6df
    • unknown's avatar
      Merge malff@bk-internal.mysql.com:/home/bk/mysql-5.1-runtime · 76a3dbb3
      unknown authored
      into  weblab.(none):/home/marcsql/TREE/mysql-5.1-rt50-merge
      
      
      76a3dbb3
    • unknown's avatar
      Merge bk-internal.mysql.com:/home/bk/mysql-5.0-runtime · 901ead6c
      unknown authored
      into  moksha.local:/Users/davi/mysql/push/mysql-5.0-runtime
      
      
      901ead6c
    • unknown's avatar
      Merge weblab.(none):/home/marcsql/TREE/mysql-5.0-runtime · f371dfea
      unknown authored
      into  weblab.(none):/home/marcsql/TREE/mysql-5.1-rt50-merge
      
      
      sql/sql_yacc.yy:
        automerge failed.
      f371dfea
    • unknown's avatar
      Bug#30625 (Performance, reduce depth for expressions) · e0e44ad6
      unknown authored
      This is a performance bug, affecting in particular the bison generated code
      for the parser.
      
      Prior to this fix, the grammar used a long chain of reduces to parse an
      expression, like:
        bit_expr -> bit_term
        bit_term -> bit_factor
        bit_factor -> value_expr
        value_expr -> term
        term -> factor
      etc
      
      This chain of reduces cause the internal state automaton in the generated
      parser to execute more state transitions and more reduces, so that the
      generated MySQLParse() function would spend a lot of time looping to execute
      all the grammar reductions.
      
      With this patch, the grammar has been reorganized so that rules are more
      "flat", limiting the depth of reduces needed to parse <expr>.
      
      Tests have been written to enforce that relative priorities and properties
      of operators have not changed while changing the grammar.
      
      See the bug report for performance data.
      
      
      mysql-test/r/parser_precedence.result:
        Improved test coverage for operator precedence
      mysql-test/t/parser_precedence.test:
        Improved test coverage for operator precedence
      sql/sql_yacc.yy:
        Simplified the grammar to improve performances
      e0e44ad6
  4. 27 Aug, 2007 4 commits
    • unknown's avatar
      Bug#30632 HANDLER read failure causes hang · 34ded629
      unknown 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.
      
      
      mysql-test/r/handler.result:
        Bug#30632 test case result
      mysql-test/t/handler.test:
        Bug#30632 test case
      sql/sql_handler.cc:
        Always unlock the internal and external table level locks if any of the conditions
        (including errors) to read from a HANDLER table are not met.
      34ded629
    • unknown's avatar
      Merge moksha.local:/Users/davi/mysql/push/mysql-5.1-runtime · 4e69921f
      unknown authored
      into  moksha.local:/Users/davi/mysql/push/bugs/29936-5.1
      
      
      4e69921f
    • unknown's avatar
      Merge moksha.local:/Users/davi/mysql/push/bugs/25164-5.0 · e7d7a238
      unknown authored
      into  moksha.local:/Users/davi/mysql/push/bugs/25164-5.1
      
      
      sql/lock.cc:
        Auto merged
      mysql-test/include/deadlock.inc:
        Auto merged
      mysql-test/r/deadlock_innodb.result:
        Auto merged
      e7d7a238
    • unknown's avatar
      Bug#25164 create table `a` as select * from `A` hangs · 369a5f1c
      unknown 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.
      
      
      mysql-test/r/innodb-deadlock.result:
        Bug#25164 test case result
      mysql-test/t/innodb-deadlock.test:
        Bug#25164 test case. The CREATE TABLE may fail depending on the character set
        of the system and filesystem, but it should never hang.
      sql/lock.cc:
        Unlock the storage engine "external" table level locks, if the MySQL thr_lock
        locking subsystem detects a deadlock error.
      369a5f1c
  5. 24 Aug, 2007 4 commits
  6. 23 Aug, 2007 3 commits
    • unknown's avatar
      Bug#28285 Test "events_bugs" has instable results of "select /*1*/ ... from processlist" · 55d65833
      unknown authored
      Test case contains possible race conditions. This patch fixes these race
      conditions and also adjust the test to execute according to its documentation.
      
      
      mysql-test/r/events.result:
        Modified test case to fit test documentation
      mysql-test/t/events.test:
        Modified test case to fit test documentation
      55d65833
    • unknown's avatar
      Merge weblab.(none):/home/marcsql/TREE/mysql-5.0-cleanup · 4fd7ce7a
      unknown authored
      into  weblab.(none):/home/marcsql/TREE/mysql-5.1-cleanup
      
      
      BUILD/SETUP.sh:
        Auto merged
      4fd7ce7a
    • unknown's avatar
      Do not use $static_link for GCOV builds, · 33e123ea
      unknown authored
      since this flag was explicitly removed in pushbuild for GCOV builds.
      
       BUILD_CMD => ['sh', '-c', 'perl -i.bak -pe "s/ \\\\\$static_link//" ' .
                    'BUILD/compile-pentium-gcov; BUILD/compile-pentium-gcov'],
      
      Moving $static_link to SETUP.sh broke this, and is now fixed.
      
      Should this flag be needed on some platforms,
      the proper location is compile-<platform>-gcov
      
      Tested the amd64 and pentium64 build fine without it, and can run NDB tests.
      
      
      BUILD/SETUP.sh:
        Removed $static_link from GCOV builds.
      33e123ea
  7. 22 Aug, 2007 8 commits
    • unknown's avatar
      Bug#30333 (Performance, expressions lists in the parser) · 5dc3e889
      unknown authored
      Before this patch, the parser would execute:
      - Select->expr_list.push_front()
      - Select->expr_list.pop()
      when parsing expressions lists, in the following rules:
      - udf_expr_list
      - expr_list
      - ident_list
      
      This is unnecessary, and introduces overhead due to the memory allocations
      performed with Select->expr_list
      
      With this patch, this code has been removed.
      The list being parsed is maintained in the parser stack instead.
      
      Also, 'udf_expr_list' has been renamed 'opt_udf_expr_list', since this
      production can be empty.
      
      
      sql/sql_lex.cc:
        Removed unused attribute expr_list
      sql/sql_lex.h:
        Removed unused attribute expr_list
      sql/sql_yacc.yy:
        Improved performances when parsing expression lists
      5dc3e889
    • unknown's avatar
      Manual merge · 49fea65f
      unknown authored
      49fea65f
    • unknown's avatar
      Manual merge · d007e524
      unknown authored
      d007e524
    • unknown's avatar
      Merge weblab.(none):/home/marcsql/TREE/mysql-5.0-runtime · c34e2c7f
      unknown authored
      into  weblab.(none):/home/marcsql/TREE/mysql-5.1-rt50-merge
      
      
      BUILD/SETUP.sh:
        Auto merged
      mysql-test/r/query_cache.result:
        Auto merged
      mysql-test/t/query_cache.test:
        Auto merged
      sql/item_cmpfunc.h:
        Auto merged
      c34e2c7f
    • unknown's avatar
      Merge malff@bk-internal.mysql.com:/home/bk/mysql-5.0-runtime · 6f052e87
      unknown authored
      into  weblab.(none):/home/marcsql/TREE/mysql-5.0-30237
      
      
      6f052e87
    • unknown's avatar
      Merge malff@bk-internal.mysql.com:/home/bk/mysql-5.0-runtime · 9d173ed2
      unknown authored
      into  weblab.(none):/home/marcsql/TREE/mysql-5.0-23062
      
      
      9d173ed2
    • unknown's avatar
      Merge malff@bk-internal.mysql.com:/home/bk/mysql-5.0-runtime · d4e34c80
      unknown authored
      into  weblab.(none):/home/marcsql/TREE/mysql-5.0-30237
      
      
      sql/sql_yacc.yy:
        Auto merged
      d4e34c80
    • unknown's avatar
      Bug#30237 (Performance regression in boolean expressions) · fb1be0f1
      unknown authored
      This is a performance bug, related to the parsing or 'OR' and 'AND' boolean
      expressions.
      
      Let N be the number of expressions involved in a OR (respectively AND).
      
      When N=1
      
      For example, "select 1" involve only 1 term: there is no OR operator.
      
      In 4.0 and 4.1, parsing expressions not involving OR had no overhead.
      In 5.0, parsing adds some overhead, with Select->expr_list.
      
      With this patch, the overhead introduced in 5.0 has been removed,
      so that performances for N=1 should be identical to the 4.0 performances,
      which are optimal (there is no code executed at all)
      
      The overhead in 5.0 was in fact affecting significantly some operations.
      For example, loading 1 Million rows into a table with INSERTs,
      for a table that has 100 columns, leads to parsing 100 Millions of
      expressions, which means that the overhead related to Select->expr_list
      is executed 100 Million times ...
      
      Considering that N=1 is by far the most probable expression,
      this case should be optimal.
      
      When N=2
      
      For example, "select a OR b" involves 2 terms in the OR operator.
      
      In 4.0 and 4.1, parsing expressions involving 2 terms created 1 Item_cond_or
      node, which is the expected result.
      In 5.0, parsing these expression also produced 1 node, but with some extra
      overhead related to Select->expr_list : creating 1 list in Select->expr_list
      and another in Item_cond::list is inefficient.
      
      With this patch, the overhead introduced in 5.0 has been removed
      so that performances for N=2 should be identical to the 4.0 performances.
      Note that the memory allocation uses the new (thd->mem_root) syntax
      directly.
      The cost of "is_cond_or" is estimated to be neglectable: the real problem
      of the performance degradation comes from unneeded memory allocations.
      
      When N>=3
      
      For example, "select a OR b OR c ...", which involves 3 or more terms.
      
      In 4.0 and 4.1, the parser had no significant cost overhead, but produced
      an Item tree which is difficult to evaluate / optimize during runtime.
      In 5.0, the parser produces a better Item tree, using the Item_cond
      constructor that accepts a list of children directly, but at an extra cost
      related to Select->expr_list.
      
      With this patch, the code is implemented to take the best of the two
      implementations:
      - there is no overhead with Select->expr_list
      - the Item tree generated is optimized and flattened.
      
      This is achieved by adding children nodes into the Item tree directly,
      with Item_cond::add(), which avoids the need for temporary lists and memory
      allocation
      
      Note that this patch also provide an extra optimization, that the previous
      code in 5.0 did not provide: expressions are flattened in the Item tree,
      based on what the expression already parsed is, and not based on the order
      in which rules are reduced.
      
      For example : "(a OR b) OR c", "a OR (b OR c)" would both be represented
      with 2 Item_cond_or nodes before this patch, and with 1 node only with this
      patch. The logic used is based on the mathematical properties of the OR
      operator (it's associative), and produces a simpler tree.
      
      
      sql/item_cmpfunc.h:
        Improved performances for parsing boolean expressions
      sql/sql_yacc.yy:
        Improved performances for parsing boolean expressions
      mysql-test/r/parser_precedence.result:
        Added test cases to cover boolean operator precedence
      mysql-test/t/parser_precedence.test:
        Added test cases to cover boolean operator precedence
      fb1be0f1
  8. 21 Aug, 2007 2 commits