An error occurred fetching the project authors.
  1. 12 Apr, 2011 1 commit
  2. 11 Apr, 2011 1 commit
  3. 27 Feb, 2011 1 commit
  4. 08 Feb, 2011 1 commit
  5. 02 Feb, 2011 1 commit
  6. 18 Jan, 2011 1 commit
  7. 14 Jan, 2011 1 commit
  8. 11 Jan, 2011 2 commits
  9. 10 Jan, 2011 2 commits
  10. 30 Dec, 2010 1 commit
  11. 20 Dec, 2010 1 commit
  12. 24 Nov, 2010 2 commits
  13. 07 Nov, 2010 1 commit
  14. 01 Nov, 2010 1 commit
  15. 27 Oct, 2010 1 commit
  16. 07 Oct, 2010 1 commit
  17. 06 Oct, 2010 1 commit
  18. 24 Sep, 2010 1 commit
  19. 07 Sep, 2010 1 commit
  20. 31 Aug, 2010 1 commit
  21. 17 Aug, 2010 1 commit
  22. 03 Aug, 2010 1 commit
    • Georgi Kodinov's avatar
      Bug #42144: plugin_load fails · 534e6933
      Georgi Kodinov authored
      The enum system variables were handled inconsistently 
      as ints, unsigned int and unsigned long on various places.
      This caused problems on platforms on which 
      sizeof(int) != sizeof(long).
      Fixed by homogenizing the type of the enum variables
      to unsigned int, since it's size compatible with the C enum
      type. 
      Removed the test from the experimental list.
      534e6933
  23. 26 Jul, 2010 1 commit
  24. 28 Jun, 2010 1 commit
  25. 26 Jun, 2010 1 commit
  26. 15 Jun, 2010 1 commit
  27. 03 Jun, 2010 1 commit
  28. 01 Jun, 2010 2 commits
  29. 03 Jun, 2010 1 commit
  30. 11 May, 2010 1 commit
  31. 04 May, 2010 1 commit
  32. 30 Apr, 2010 1 commit
    • Alexander Nozdrin's avatar
      Patch for Bug#52356: query_cache_debug fails on Linux. · c784ee27
      Alexander Nozdrin authored
      There were two problems here:
        1. misleading error message
        2. abusing KILL QUERY in the test case
      
      1. The server reported "'DELETE FROM t1' failed: 1689: Wait on a lock was
      aborted due to a pending exclusive lock", while the proper error message
      should be "'DELETE FROM t1' failed: 1317: Query execution was interrupted".
      
      The problem is that the server has two different flags for
      signalling that a query is being killed: THD::killed and
      mysys_var::abort. The test case triggers a race: sometimes
      mysys_var::abort is set earlier than THD::killed. That leads
      to the following situation:
      
        - thr_lock() checks mysys_var::abort and returns error status,
          since mysys_var::abort is set;
      
        - the caller (mysql_lock_tables()) gets an error from thr_lock(),
          but THD::killed is not set, so it decides that thr_lock() couldn't
          get a lock due to a pending exclusive lock.
      
      This is a known issue with the server and it's not going to be fixed soon.
      
      5.5 differs from 5.1 here as follows: when thr_lock() returns an error:
        - 5.1 continues trying thr_lock() until success;
        - 5.5 propagates the error
      
      2. The test case uses KILL QUERY is a highly concurent environment.
      
      The fix is to wait for the dying statement to rest in peace before
      executing another DELETE FROM t1.
      c784ee27
  33. 26 Apr, 2010 1 commit
  34. 10 Apr, 2010 1 commit
  35. 23 Mar, 2010 1 commit
  36. 22 Mar, 2010 1 commit