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
===================================================================

into  mysql.com:/windows/Linux_space/MySQL/mysql-5.0-ndb

into  whalegate.ndb.mysql.com:/home/tomas/mysql-5.0-ndb-bj

into  dev3-63.(none):/home/zhl/mysql/mysql-5.0/bug29674

into  dev3-63.(none):/home/zhl/mysql/mysql-5.0/bug29674

into  dev3-240.dev.cn.tlan:/home/justin.he/mysql/mysql-5.0/mysql-5.0-ndb-bj.merge

into  dev3-63.(none):/home/zhl/mysql/mysql-5.0/bug29674

into  mysql.com:/windows/Linux_space/MySQL/mysql-5.0-ndb

into  perch.ndb.mysql.com:/home/jonas/src/mysql-5.0-ndb

ChangeSet@1.2575, 2007-08-07 19:16:06+02:00, msvensson@pilot.(none) +2 -0
  Bug#26793 mysqld crashes when doing specific query on information_schema
   - Drop the newly created user user1@localhost
   - Cleanup testcase

bug#30337  DELETE ... WHERE PK IN (..) and AFTER DELETE trigger crashes API node: Disable multi_read_range if there are after delete/update triggers

  Handle out of transaction buffer in TC for INDX lookups

into  dev3-221.dev.cn.tlan:/home/ngb/mysql/mysql-5.0/bug28423

into  dev3-221.dev.cn.tlan:/home/ngb/mysql/mysql-5.0/bug27683

into  dev3-63.(none):/home/zhl/mysql/mysql-5.0/bug23354

If ::exteral_lock hadn't been called, we'd have no NDB object,
so need to check/get one here.

It looks like sql_show.cc is the only place that does this....
or at least the other places will be well hidden.

Index: ndb-work/sql/ha_ndbcluster.cc
===================================================================

Reduce case and formalise into something we should be
able to use in mysql-test-run.

Index: ndb-work/mysql-test/t/ndb_bug26793.test
===================================================================

into  whalegate.ndb.mysql.com:/home/tomas/mysql-5.0-ndb

into  perch.ndb.mysql.com:/home/jonas/src/mysql-5.0-ndb

  dont assert if 2 LCP's are being run during a node recovery

into  dev3-63.(none):/home/zhl/mysql/mysql-5.0/bug25941

into  perch.ndb.mysql.com:/home/jonas/src/mysql-5.0-ndb

  Not very clever fix for DIH incorrect REDO handling
  - Dont report GCP_SAVE_CONF until first LCP has been complete during NR

into  perch.ndb.mysql.com:/home/jonas/src/mysql-5.0-ndb

  In TC init node status for already started nodes during node restart
  (not present in 5.1)

  Fix 3 problems in REDO validation that could(will) lead to "Error while reading REDO log"