An error occurred fetching the project authors.
  1. 28 Nov, 2008 1 commit
    • Georgi Kodinov's avatar
      Bug #37339: SHOW VARIABLES not working properly with multi-byte datadir · 0708ad5f
      Georgi Kodinov authored
            
      The SHOW VARIABLES LIKE .../SELECT @@/SELECT ... FROM INFORMATION_SCHEMA.VARIABLES
      were assuming that all the system variables are in system charset (UTF-8).
      However the variables that are settable through command line will have a different
      character set (character_set_filesystem).
      Fixed the server to remember the correct character set of basedir, datadir, tmpdir,
      ssl, plugin_dir, slave_load_tmpdir, innodb variables; init_connect and init_slave 
      variables and use it when processing data.
      0708ad5f
  2. 25 Aug, 2008 1 commit
  3. 16 Jul, 2008 1 commit
  4. 19 Jun, 2008 1 commit
  5. 28 Mar, 2008 1 commit
  6. 21 Dec, 2007 3 commits
  7. 19 Dec, 2007 1 commit
  8. 06 Dec, 2007 1 commit
  9. 30 Nov, 2007 1 commit
    • tnurnberg@mysql.com/white.intern.koehntopp.de's avatar
      Bug#31177: Server variables can't be set to their current values · 31d4e58a
      Default values of variables were not subject to upper/lower bounds
      and step, while setting variables was. Bounds and step are also
      applied to defaults now; defaults are corrected quietly, values
      given by the user are corrected, and a correction-warning is thrown
      as needed. Lastly, very large values could wrap around, starting
      from 0 again. They are bounded at the maximum value for the
      respective data-type now if no lower maximum is specified in the
      variable's definition.
      31d4e58a
  10. 26 Nov, 2007 1 commit
  11. 25 Oct, 2007 1 commit
    • kaa@polly.(none)'s avatar
      Fix for bug #29131: SHOW VARIABLES reports variable 'log' but SET · 99f4b743
      kaa@polly.(none) authored
      doesn't recognize it
      
      This is a 5.0 version of the patch, it will be null-merged to 5.1
      
      Problem:
      
      'log' and 'log_slow_queries' were "fixed" variables, i.e. they showed up
      in SHOW VARIABLES, but could not be used in expressions like 
      "select @@log". Also, using them in the SET statement produced an 
      incorrect "unknown system variable" error.
      
      Solution:
      
      Make 'log' and 'log_slow_queries' read-only dynamic variables to make 
      them available for use in expressions, and produce a correct error 
      about the variable being read-only when used in the SET statement.
      99f4b743
  12. 18 Oct, 2007 1 commit
  13. 17 Oct, 2007 1 commit
  14. 10 Oct, 2007 1 commit
  15. 04 Oct, 2007 1 commit
  16. 03 Oct, 2007 1 commit
  17. 28 Sep, 2007 1 commit
  18. 30 Jul, 2007 1 commit
    • gkodinov/kgeorge@magare.gmz's avatar
      (pushing for Andrei) · 9a0e6ec6
      gkodinov/kgeorge@magare.gmz authored
      Bug #27417 thd->no_trans_update.stmt lost value inside of SF-exec-stack
        
      Once had been set the flag might later got reset inside of a stored routine 
      execution stack.
      The reason was in that there was no check if a new statement started at time 
      of resetting.
      The artifact affects most of binlogable DML queries. Notice, that multi-update 
      is wrapped up within
        bug@27716 fix, multi-delete bug@29136.
        
      Fixed with saving parent's statement flag of whether the statement modified 
      non-transactional table, and unioning (merging) the value with that was gained 
      in mysql_execute_command.
        
      Resettling thd->no_trans_update members into thd->transaction.`member`;
      Asserting code;
      Effectively the following properties are held.
        
      1. At the end of a substatement thd->transaction.stmt.modified_non_trans_table
         reflects the fact if such a table got modified by the substatement.
         That also respects THD::really_abort_on_warnin() requirements.
      2. Eventually thd->transaction.stmt.modified_non_trans_table will be computed as
         the union of the values of all invoked sub-statements.
         That fixes this bug#27417;
      
      Computing of thd->transaction.all.modified_non_trans_table is refined to base to 
      the stmt's value for all the case including insert .. select statement which 
      before the patch had an extra issue bug@28960.
      Minor issues are covered with mysql_load, mysql_delete, and binloggin of insert in
      to temp_table select. 
        
      The supplied test verifies limitely, mostly asserts. The ultimate testing is defered
      for bug@13270, bug@23333.
      9a0e6ec6
  19. 11 Jul, 2007 1 commit
    • gkodinov/kgeorge@magare.gmz's avatar
      Bug #29325: · 015e1290
      gkodinov/kgeorge@magare.gmz authored
      By default MyISAM overwrites .MYD and .MYI files no 
      DATA DIRECTORY option is used. This can lead to two tables
      using the same .MYD and .MYI files (that can't be dropped).
      
      To prevent CREATE TABLE from overwriting a file a new option
      is introduced : keep_files_on_create
      When this is on the CREATE TABLE throws an error if either
      the .MYD or .MYI exists for a MyISAM table.
      The option is off by default (resulting in compatible behavior).
      015e1290
  20. 03 Jun, 2007 1 commit
    • gkodinov/kgeorge@macbook.gmz's avatar
      Bug #26162: Trigger DML ignores low_priority_updates setting · 9a1d8adc
      gkodinov/kgeorge@macbook.gmz authored
        
      The value of "low-priority-updates" option and the LOW PRIORITY
      prefix was taken into account at parse time.
      This caused triggers (among others) to ignore this flag (if
      supplied for the DML statement).
      Moved reading of the LOW_PRIORITY flag at run time.
      Fixed an incosistency when handling
      SET GLOBAL LOW_PRIORITY_UPDATES : now it is in effect for
      delayed INSERTs.
      Tested by checking the effect of LOW_PRIORITY flag via a 
      trigger.
      9a1d8adc
  21. 24 May, 2007 1 commit
    • msvensson@pilot.blaudden's avatar
      Bug#26664 test suite times out on OS X 64bit · 93b1fe65
      msvensson@pilot.blaudden authored
       - The "mysql client in mysqld"(which is used by
         replication and federated) should use alarms instead of setting
         socket timeout value if the rest of the server uses alarm. By
         always calling 'my_net_set_write_timeout'
         or 'my_net_set_read_timeout' when changing the timeout value(s), the
         selection whether to use alarms or timeouts will be handled by
         ifdef's in those two functions. 
       - Move declaration of 'vio_timeout' into "vio_priv.h"
      93b1fe65
  22. 08 May, 2007 2 commits
    • thek@adventure.(none)'s avatar
      5e774747
    • thek@adventure.(none)'s avatar
      Bug #27792 query cache returns wrong result, with certain system variables · 4ea05eae
      thek@adventure.(none) authored
       - Queries in the query cache are identified by the individual 
         characters in the query statement, the current database and 
         the current environment expressed as a set of system variable
         flags.
       - Since the set of environment flags didn't properly describe the
         current environment unexpected results were returned from the 
         query cache.
       - Query cache is now cleared when the variable ft_boolean_syntax is 
         updated.
       - An identification flag for the variable default_week_format is 
         added to the query cache record.
       
      Thanks to Martin Friebe who has supplied significant parts of this patch.
      4ea05eae
  23. 09 Apr, 2007 1 commit
    • bar@mysql.com's avatar
      Bug#22648 LC_TIME_NAMES: Setting GLOBAL has no effect · 4341df8c
      bar@mysql.com authored
      Problem: setting/displaying @@LC_TIME_NAMES didn't distinguish between
      GLOBAL and SESSION variable types - always SESSION variable
      was set/shonw.
      Fix: set either global or session value.
      Also, "mysqld --lc-time-names" was added to set "global default" value.
      4341df8c
  24. 23 Mar, 2007 1 commit
    • aelkin/elkin@andrepl.(none)'s avatar
      Bug #27395 OPTION_STATUS_NO_TRANS_UPDATE is not preserved at the end of SF() · 2afa90b5
      aelkin/elkin@andrepl.(none) authored
      thd->options' OPTION_STATUS_NO_TRANS_UPDATE bit was not restored at the end of SF() invocation, where
      SF() modified non-ta table.
      As the result of this artifact it was not possible to detect whether there were any side-effects when
      top-level query ends. 
      If the top level query table was not modified and the bit is lost there would be no binlogging.
      
      Fixed with preserving the bit inside of thd->no_trans_update struct. The struct agregates two bool flags
      telling whether the current query and the current transaction modified any non-ta table.
      The flags stmt, all are dropped at the end of the query and the transaction.
      2afa90b5
  25. 12 Mar, 2007 1 commit
  26. 05 Mar, 2007 1 commit
  27. 20 Feb, 2007 1 commit
  28. 14 Feb, 2007 1 commit
  29. 29 Jan, 2007 1 commit
  30. 23 Dec, 2006 1 commit
  31. 19 Dec, 2006 1 commit
  32. 14 Dec, 2006 1 commit
    • monty@mysql.com/narttu.mysql.fi's avatar
      Fixed compiler warnings detected by option -Wshadow and -Wunused: · 88dd873d
      monty@mysql.com/narttu.mysql.fi authored
      - Removed not used variables and functions
      - Added #ifdef around code that is not used
      - Renamed variables and functions to avoid conflicts
      - Removed some not used arguments
      
      Fixed some class/struct warnings in ndb
      Added define IS_LONGDATA() to simplify code in libmysql.c
      
      I did run gcov on the changes and added 'purecov' comments on almost all lines that was not just variable name changes
      88dd873d
  33. 05 Dec, 2006 1 commit
  34. 30 Nov, 2006 1 commit
  35. 27 Nov, 2006 1 commit
  36. 21 Nov, 2006 1 commit
  37. 30 Oct, 2006 1 commit