An error occurred fetching the project authors.
  1. 27 Nov, 2006 1 commit
  2. 20 Nov, 2006 1 commit
    • monty@mysql.com/nosik.monty.fi's avatar
      Remove compiler warnings · e8258798
      monty@mysql.com/nosik.monty.fi authored
      (Mostly in DBUG_PRINT() and unused arguments)
      Fixed bug in query cache when used with traceing (--with-debug)
      Fixed memory leak in mysqldump
      Removed warnings from mysqltest scripts (replaced -- with #)
      e8258798
  3. 30 Oct, 2006 2 commits
    • kroki/tomash@moonlight.intranet's avatar
      BUG#21915: Changing limits of table_cache when setting max_connections · 1bfe00e0
      kroki/tomash@moonlight.intranet authored
      If the user has specified --max-connections=N or --table-open-cache=M
      options to the server, a warning could be given that some values were
      recalculated, and table-open-cache could be assigned greater value.
      
      Note that both warning and increase of table-open-cache were totally
      harmless.
      
      This patch fixes recalculation code to ensure that table-open-cache will
      be never increased automatically and that a warning will be given only if
      some values had to be decreased due to operating system limits.
      
      No test case is provided because we neither can't predict nor control
      operating system limits for maximal number of open files.
      1bfe00e0
    • msvensson@shellback.(none)'s avatar
      Improve comments around FLUSH STATUS · e8c7f191
      msvensson@shellback.(none) authored
      It's not possible to flush the global status variables in 5.0
      Update test case so it works by recording the value of handle_rollback
      before and compare it to the value after
      e8c7f191
  4. 15 Sep, 2006 1 commit
  5. 06 Sep, 2006 1 commit
  6. 21 Aug, 2006 1 commit
  7. 17 Aug, 2006 1 commit
  8. 11 Aug, 2006 1 commit
    • bar@mysql.com/bar.intranet.mysql.r18.ru's avatar
      mysqld --collation-server=xxx --character-set-server=yyy · 4a63a64f
      didn't work as expected: collation_server was set not to xxx,
      but to the default collation of character set "yyy".
          
      With different argument order it worked as expected:
      mysqld --character-set-server=yyy --collation-server=yyy 
          
      Fix:
      initializate default_collation_name to 0
      when processing --character-set-server
      only if --collation-server has not been specified
      in command line.
      4a63a64f
  9. 04 Aug, 2006 1 commit
  10. 03 Aug, 2006 3 commits
    • iggy@rolltop.ignatz42.dyndns.org's avatar
    • msvensson@neptunus.(none)'s avatar
      Bug#21419 test case lowercase_fs_off fails on Windows · 5fc215e2
      msvensson@neptunus.(none) authored
       - Backport patch from 5.0
      5fc215e2
    • malff/marcsql@weblab.(none)'s avatar
      Bug#8153 (Stored procedure with subquery and continue handler, wrong result) · 21f00113
      malff/marcsql@weblab.(none) authored
      Before this fix,
      - a runtime error in a statement in a stored procedure with no error handlers
      was properly detected (as expected)
      - a runtime error in a statement with an error handler inherited from a non
      local runtime context (i.e., proc a with a handler, calling proc b) was
      properly detected (as expected)
      - a runtime error in a statement with a *local* error handler was executed
      as follows :
      a) the statement would succeed, regardless of the error condition, (bug)
      b) the error handler would be called (as expected).
      
      The root cause is that functions like my_messqge_sql would "forget" to set
      the thread flag thd->net.report_error to 1, because of the check involving
      sp_rcontext::found_handler_here().
      Failure to set this flag would cause, later in the call stack,
      in Item_func::fix_fields() at line 190, the code to return FALSE and consider
      that executing the statement was successful.
      
      With this fix :
      - error handling code, that was duplicated in different places in the code,
      is now implemented in sp_rcontext::handle_error(),
      - handle_error() correctly sets thd->net.report_error when a handler is
      present, regardless of the handler location (local, or in the call stack).
      
      A test case, bug8153_subselect, has been written to demonstrate the change
      of behavior before and after the fix.
      
      Another test case, bug8153_function_a, as also been writen.
      This test has the same behavior before and after the fix.
      This test has been written to demonstrate that the previous expected
      result of procedure bug18787, was incorrect, since select no_such_function()
      should fail and therefore not produce a result.
      
      The incorrect result for bug18787 has the same root cause as Bug#8153,
      and the expected result has been adjusted.
      21f00113
  11. 31 Jul, 2006 1 commit
  12. 21 Jul, 2006 1 commit
  13. 20 Jul, 2006 1 commit
  14. 14 Jul, 2006 1 commit
  15. 23 Jun, 2006 1 commit
    • bar@mysql.com's avatar
      Bug#15276: MySQL ignores collation-server · ee8fd1e3
      bar@mysql.com authored
          Problem:
          mysqld --collation-server=xxx --character-set-server=yyy
          didn't work as expected: collation_server was set not to xxx,
          but to the default collation of character set "yyy".
          
          With different argument order it worked as expected:
          mysqld --character-set-server=yyy --collation-server=yyy 
          
          Fix:
          initializate default_collation_name to 0
          when processing --character-set-server
          only if --collation-server has not been specified
          in command line.
      ee8fd1e3
  16. 21 Jun, 2006 1 commit
  17. 20 Jun, 2006 1 commit
  18. 07 Jun, 2006 1 commit
  19. 31 May, 2006 1 commit
  20. 24 May, 2006 1 commit
    • monty@mysql.com's avatar
      More DBUG statements · 9e9ca8b6
      monty@mysql.com authored
      Replaced COND_refresh with COND_global_read_lock becasue of a bug in NTPL threads when using different mutexes as arguments to pthread_cond_wait()
      The original code caused a hang in FLUSH TABLES WITH READ LOCK in some circumstances because pthread_cond_broadcast() was not delivered to other threads.
      This fixes:
      Bug#16986: Deadlock condition with MyISAM tables
      Bug#20048: FLUSH TABLES WITH READ LOCK causes a deadlock
      9e9ca8b6
  21. 23 May, 2006 1 commit
  22. 19 May, 2006 2 commits
  23. 15 May, 2006 1 commit
  24. 08 May, 2006 2 commits
    • jimw@mysql.com's avatar
      Bug #1039: tmpdir and datadir not available via @@ system variable syntax · ebe38efa
      jimw@mysql.com authored
      Bug #19606: ssl variables are not displayed in show variables
      Bug #19616: log_queries_not_using_indexes  is not listed in show variables
      
        Make basedir, datadir, tmpdir, log_queries_not_using_indexes, ssl_ca,
        ssl_capath, ssl_cert, ssl_cipher, and ssl_key all available both from
        SHOW VARIABLES and as @@variables.
      
        As a side-effect of this change, log_queries_not_using_indexes can
        be changed at runtime (but only globally, not per-connection).
      ebe38efa
    • msvensson@neptunus.(none)'s avatar
      Remove valgrind and compiler warnings · b60540a8
      msvensson@neptunus.(none) authored
      Add function 'vio_end' that will cleanup resources allocated by vio and the components it uses.
      b60540a8
  25. 28 Apr, 2006 1 commit
  26. 13 Apr, 2006 3 commits
  27. 12 Apr, 2006 1 commit
  28. 10 Apr, 2006 1 commit
  29. 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
    • kroki@mysql.com's avatar
      Bug#15933: max_used_connections is wrong after FLUSH STATUS if connections are cached · 6222ca41
      kroki@mysql.com authored
      After FLUSH STATUS max_used_connections was reset to 0, and haven't
      been updated while cached threads were reused, until the moment a new
      thread was created.
      
      The first suggested fix from original bug report was implemented:
      
        a) On flushing the status, set max_used_connections to
        threads_connected, not to 0.
      
        b) Check if it is necessary to increment max_used_connections when
        taking a thread from the cache as well as when creating new threads
      6222ca41
  30. 16 Mar, 2006 1 commit
    • acurtis@xiphis.org's avatar
      Bug#14575 · 63fb6609
      acurtis@xiphis.org authored
        ¨MySQL server crashes if you try to access to InnoDB table¨
        crash caused by schizophrenic mysqld - 2 memory locations for logically same function
        with conflicting values.
        Fixed by backporting from 5.1 changes to have_xyz_db declarations.
      63fb6609
  31. 14 Mar, 2006 1 commit
  32. 10 Mar, 2006 1 commit