An error occurred fetching the project authors.
  1. 19 Oct, 2006 1 commit
    • kroki/tomash@moonlight.intranet's avatar
      BUG#21856: Prepared Statements: crash if bad create · 00b2fc6a
      kroki/tomash@moonlight.intranet authored
      When statement to be prepared contained CREATE PROCEDURE, CREATE FUNCTION
      or CREATE TRIGGER statements with a syntax error in it, the preparation
      would fail with syntax error message, but the memory could be corrupted.
      
      The problem occurred because we switch memroot when parse stored
      routine or trigger definitions, and on parse error we restored the
      original memroot only after performing some memory operations.  In more
      detail:
       - prepared statement would activate its own memory root to parse
         the definition of the stored procedure.
       - SP would reset this memory root with its own memory root to
         parse SP statements
       - a syntax error would happen
       - prepared statement would restore the original memory root
       - stored procedure would restore what it thinks was the original
         memory root, but actually was the statement memory root.
      That led to double free - in destruction of the statement and in
      a next call to mysql_parse().
      
      The solution is to restore memroot right after the failed parsing.
      00b2fc6a
  2. 10 Oct, 2006 1 commit
  3. 27 Sep, 2006 1 commit
    • kroki/tomash@moonlight.intranet's avatar
      BUG#21081: SELECT inside stored procedure returns wrong results · 0bdc597b
      kroki/tomash@moonlight.intranet authored
      Re-execution of a parametrized prepared statement or a stored routine
      with a SELECT that use LEFT JOIN with second table having only one row
      could yield incorrect result.
      
      The problem appeared only for left joins with second table having only
      one row (aka const table) and equation conditions in ON or WHERE clauses
      that depend on the argument passed.  Once the condition was false for
      second const table, a NULL row was created for it, and any field involved
      got NULL-value flag, which then was never reset.
      
      The cause of the problem was that Item_field::null_value could be set
      without being reset for re-execution.  The solution is to reset
      Item_field::null_value in Item_field::cleanup().
      0bdc597b
  4. 19 Sep, 2006 1 commit
  5. 16 Sep, 2006 1 commit
    • igor@rurik.mysql.com's avatar
      Fixed bug #22085: Crash on the execution of a prepared · dd3b8e4f
      igor@rurik.mysql.com authored
      statement that uses an aggregating IN subquery with 
      HAVING clause.
      A wrong order of the call of split_sum_func2 for the HAVING
      clause of the subquery and the transformation for the 
      subquery resulted in the creation of a andor structure
      that could not be restored at an execution of the prepared
      statement.
      dd3b8e4f
  6. 24 Aug, 2006 1 commit
  7. 11 Jul, 2006 1 commit
  8. 06 Jul, 2006 1 commit
    • konstantin@bodhi.netgear's avatar
      A fix and a test case for Bug#19399 "res 'Lost Connection' when · 8e735d2c
      konstantin@bodhi.netgear authored
      dropping/creating tables".
      
      The bug could lead to a crash when multi-delete statements were
      prepared and used with temporary tables.
      
      The bug was caused by lack of clean-up of multi-delete tables before
      re-execution of a prepared statement. In a statement like
      DELETE t1 FROM t1, t2 WHERE ... the first table list (t1) is
      moved to lex->auxilliary_table_list and excluded from lex->query_tables
      or select_lex->tables. Thus it was unaccessible to reinit_stmt_before_use
      and not cleaned up before re-execution of a prepared statement. 
      8e735d2c
  9. 26 Jun, 2006 1 commit
    • konstantin@mysql.com's avatar
      A fix and a test case for · 117b76a5
      konstantin@mysql.com authored
       Bug#19022 "Memory bug when switching db during trigger execution"
       Bug#17199 "Problem when view calls function from another database."
       Bug#18444 "Fully qualified stored function names don't work correctly in
                  SELECT statements"
      
       Documentation note: this patch introduces a change in behaviour of prepared
       statements.
      
       This patch adds a few new invariants with regard to how THD::db should
       be used. These invariants should be preserved in future:
      
        - one should never refer to THD::db by pointer and always make a deep copy
          (strmake, strdup)
        - one should never compare two databases by pointer, but use strncmp or
          my_strncasecmp
        - TABLE_LIST object table->db should be always initialized in the parser or
          by creator of the object.
      
          For prepared statements it means that if the current database is changed
          after a statement is prepared, the database that was current at prepare
          remains active. This also means that you can not prepare a statement that
          implicitly refers to the current database if the latter is not set.
          This is not documented, and therefore needs documentation. This is NOT a
          change in behavior for almost all SQL statements except:
           - ALTER TABLE t1 RENAME t2 
           - OPTIMIZE TABLE t1
           - ANALYZE TABLE t1
           - TRUNCATE TABLE t1 --
           until this patch t1 or t2 could be evaluated at the first execution of
           prepared statement. 
      
           CURRENT_DATABASE() still works OK and is evaluated at every execution
           of prepared statement.
      
           Note, that in stored routines this is not an issue as the default
           database is the database of the stored procedure and "use" statement
           is prohibited in stored routines.
      
        This patch makes obsolete the use of check_db_used (it was never used in the
        old code too) and all other places that check for table->db and assign it
        from THD::db if it's NULL, except the parser.
      
       How this patch was created: THD::{db,db_length} were replaced with a
       LEX_STRING, THD::db. All the places that refer to THD::{db,db_length} were
       manually checked and:
        - if the place uses thd->db by pointer, it was fixed to make a deep copy
        - if a place compared two db pointers, it was fixed to compare them by value
          (via strcmp/my_strcasecmp, whatever was approproate)
       Then this intermediate patch was used to write a smaller patch that does the
       same thing but without a rename.
      
       TODO in 5.1:
         - remove check_db_used
         - deploy THD::set_db in mysql_change_db
      
       See also comments to individual files.
      117b76a5
  10. 29 May, 2006 1 commit
  11. 25 Apr, 2006 1 commit
  12. 12 Apr, 2006 1 commit
  13. 07 Apr, 2006 2 commits
    • konstantin@mysql.com's avatar
      A fix and a test case for Bug#16365 "Prepared Statements: DoS with · 51899331
      konstantin@mysql.com authored
      too many open statements". The patch adds a new global variable
      @@max_prepared_stmt_count. This variable limits the total number
      of prepared statements in the server. The default value of
      @@max_prepared_stmt_count is 16382. 16382 small statements
      (a select against 3 tables with GROUP, ORDER and LIMIT) consume 
      100MB of RAM. Once this limit has been reached, the server will 
      refuse to prepare a new statement and return ER_UNKNOWN_ERROR 
      (unfortunately, we can't add new errors to 4.1 without breaking 5.0). The limit is changeable after startup
      and can accept any value from 0 to 1 million. In case
      the new value of the limit is less than the current
      statement count, no new statements can be added, while the old
      still can be used. Additionally, the current count of prepared 
      statements is now available through a global read-only variable 
      @@prepared_stmt_count.
      51899331
    • konstantin@mysql.com's avatar
      A fix and a test case for Bug#16248 "WHERE (col1,col2) IN ((?,?)) · 15b59156
      konstantin@mysql.com authored
      gives wrong results". Implement previously missing 
      Item_row::cleanup. The bug is not repeatable in 5.0, probably 
      due to a coincidence: the problem is present in 5.0 as well.
      15b59156
  14. 28 Mar, 2006 1 commit
  15. 23 Feb, 2006 1 commit
  16. 21 Feb, 2006 1 commit
  17. 16 Jan, 2006 1 commit
  18. 14 Jan, 2006 1 commit
  19. 25 Nov, 2005 1 commit
  20. 23 Nov, 2005 1 commit
  21. 08 Sep, 2005 1 commit
  22. 06 Sep, 2005 1 commit
  23. 28 Jul, 2005 1 commit
  24. 15 Jul, 2005 2 commits
  25. 14 Jul, 2005 3 commits
  26. 13 Jul, 2005 4 commits
  27. 20 Jun, 2005 2 commits
  28. 07 Jun, 2005 1 commit
  29. 16 May, 2005 1 commit
  30. 05 May, 2005 2 commits
  31. 03 May, 2005 1 commit