1. 09 Oct, 2007 1 commit
  2. 08 Oct, 2007 10 commits
  3. 03 Oct, 2007 5 commits
  4. 02 Oct, 2007 4 commits
  5. 01 Oct, 2007 2 commits
  6. 29 Sep, 2007 1 commit
  7. 28 Sep, 2007 4 commits
  8. 27 Sep, 2007 1 commit
  9. 25 Sep, 2007 5 commits
    • mikael@dator6.(none)'s avatar
      Merge dator6.(none):/home/mikael/mysql_clones/mysql-5.1-ndb · b22826fe
      mikael@dator6.(none) authored
      into  dator6.(none):/home/mikael/mysql_clones/bug30996
      b22826fe
    • stewart@willster.(none)'s avatar
      ndb_rand.c: · 5a67e7eb
      stewart@willster.(none) authored
        Rename: ndb/src/common/util/ndb_rand.c -> storage/ndb/src/common/util/ndb_rand.c
      ndb_rand.h:
        Rename: ndb/include/util/ndb_rand.h -> storage/ndb/include/util/ndb_rand.h
      5a67e7eb
    • stewart@willster.(none)'s avatar
      Merge willster.(none):/home/stewart/Documents/MySQL/5.0/ndb · efba7552
      stewart@willster.(none) authored
      into  willster.(none):/home/stewart/Documents/MySQL/5.1/ndb
      efba7552
    • stewart@flamingspork.com[stewart]'s avatar
      [PATCH] BUG#30379 Better randomise time before retry in timeout check (DBTC) · 33412d2b
      stewart@flamingspork.com[stewart] authored
      timoOutLoopStartLab() checks if any transactions have been delayed
      for so long that we are forced to perform some action (e.g. abort,
      resend etc).
      
      It is *MEANT* to (according to the comment):
      > To avoid aborting both transactions in a deadlock detected by time-out
      > we insert a random extra time-out of upto 630 ms by using the lowest
      > six bits of the api connect reference.
      > We spread it out from 0 to 630 ms if base time-out is larger than 3 sec,
      > we spread it out from 0 to 70 ms if base time-out is smaller than 300 msec,
      > and otherwise we spread it out 310 ms.
      
      The comment (as all do) lies.
      
      the API connect reference is not very random, producing incredibly
      predictable "random" numbers. This could lead to both txns being
      aborted instead of just one.
      
      Before:
      timeout value: 123 3
      timeout value: 122 2
      timeout value: 122 2
      timeout value: 122 2
      timeout value: 123 3
      
      After:
      timeout value: 127 7
      timeout value: 126 6
      timeout value: 129 9
      timeout value: 139 19
      timeout value: 137 17
      timeout value: 151 31
      timeout value: 130 10
      timeout value: 132 12
      
      Index: ndb-work/ndb/src/kernel/blocks/dbtc/DbtcMain.cpp
      ===================================================================
      33412d2b
    • mikael@dator6.(none)'s avatar
      Merge dator6.(none):/home/mikael/mysql_clones/mysql-5.1-ndb · c134b5a3
      mikael@dator6.(none) authored
      into  dator6.(none):/home/mikael/mysql_clones/bug30996
      c134b5a3
  10. 24 Sep, 2007 2 commits
  11. 20 Sep, 2007 2 commits
  12. 19 Sep, 2007 1 commit
  13. 15 Sep, 2007 1 commit
  14. 14 Sep, 2007 1 commit
    • gkodinov/kgeorge@magare.gmz's avatar
      Bug #31001: ORDER BY DESC in InnoDB not working · dc028202
      gkodinov/kgeorge@magare.gmz authored
      The optimizer sets index traversal in reverse order only if there are 
      used key parts that are not compared to a constant.
      However using the primary key as an ORDER BY suffix rendered the check
      incomplete : going in reverse order must still be used even if 
      all the parts of the secondary key are compared to a constant.
      
      Fixed by relaxing the check and set reverse traversal even when all
      the secondary index keyparts are compared to a const.
      Also account for the case when all the primary keys are compared to a
      constant.
      dc028202