bk commit into 5.1 tree (jonas:1.2066)

[jonas]

Below is the list of changes that have just been committed into a local
5.1 repository of jonas. When jonas does a push these changes will
be propagated to the main repository and, within 24 hours after the
push, to the public repository.
For information on how to access the public repository
see http://dev.mysql.com/doc/mysql/en/installing-source-tree.html

ChangeSet@stripped, 2006-10-13 09:27:45+02:00, jonas@stripped +2 -0
  ndb - drop5p16
    update changelog
    add drop5p16_new_dumps.txt

  cluster_change_hist.txt@stripped, 2006-10-13 09:27:44+02:00, jonas@stripped +20 -0
    Update changelog

  drop5p16_new_dumps.txt@stripped, 2006-10-13 09:25:40+02:00, jonas@stripped +105 -0
    BitKeeper file /home/jonas/src/mysql-5.1-wl2325-5.0/drop5p16_new_dumps.txt

  drop5p16_new_dumps.txt@stripped, 2006-10-13 09:25:40+02:00, jonas@stripped +0 -0

# This is a BitKeeper patch.  What follows are the unified diffs for the
# set of deltas contained in the patch.  The rest of the patch, the part
# that BitKeeper cares about, is below these diffs.
# User:	jonas
# Host:	perch.ndb.mysql.com
# Root:	/home/jonas/src/mysql-5.1-wl2325-5.0

--- 1.5/cluster_change_hist.txt	2006-10-13 09:27:49 +02:00
+++ 1.6/cluster_change_hist.txt	2006-10-13 09:27:49 +02:00
@@ -11,6 +11,26 @@
 
 -------------------------------
 
+Alcatel Drop 5p16 (Fri: 13 Oct 2006)
+
+As drop5p15c with additional bug fixed:
+
+    * 32/64 bit problem in slave-optimiztion-patch (also included in drop 5p14f)
+    * Bug #20252 - Batch parameter to scan
+    * Bug #20895 - Occational LCP stop CSC#8039
+    * Bug #15303 - incorrect handling of take-over during sr CSC#11089 (and possibly
others)
+    * Bug #21941 - close scan before execute yields segv
+    * Bug #22893 - inconsistent node (should be _very_ rare) CSC #10982
+    * Bug #22696 - rare combination of SR and NR CSC #11563
+    * Bug #22892 - bug in REDO handling could be the cause of several issues
+    * Bug #13987 - bug in error handling in ndb_mgmd/mgmclient protcol CSC#11100,
CSC#10800
+    * Bug #23107 - bug in handling TransactionInactiveTimeout during some circumstances
wrt Scan CSC#11911
+    * Bug #23210 - race condition in LCP/GCP during Node recovery CSC#11814 
+
+Also includes 3 new dump commands (described in drop5p16_new_dumps.txt)
+
+-------------------------------
+
 Alcatel Drop 5p14f (4 Oct 2006)
 
 As drop 5p14e but with additional bug fix below
--- New file ---
+++ drop5p16_new_dumps.txt	06/10/13 09:25:40
Description of new dump commands added in drop5p16
--------------------------------------------------

X dump 2550 <transaction filter>+
X dump 2350 <operation filter>+
X dump 2352 <op no>

<transaction filter> :=
  1 <api node id>              |
  2 <trans id 0> <trans id 1>  |
  4 <inactive time in seconds>

<operation filter> :=
  0 <table id>                 |
  1 <api node id>              |
  2 <trans id 0> <trans id 1>  |
  3 <tc node id>


E.g dump all transactions on node 2, from which has been incative for 30 seconds
ndb_mgm> 2 dump 2550 4 30
2006-10-09 13:16:49 [MgmSrvr] INFO     -- Node 2: Starting dump of transactions
2006-10-09 13:16:49 [MgmSrvr] INFO     -- Node 2: TRX[123]: API: 5(0x8035) transid: 0x31c
0x3500500 inactive: 42s state: 
2006-10-09 13:16:49 [MgmSrvr] INFO     -- Node 2: End of transaction dump 

E.g dump all operations on node 2, from api node 5
ndb_mgm> 2 dump 2350 1 5
2006-10-09 13:16:49 [MgmSrvr] INFO     -- Node 2: Starting dump of operations
2006-10-09 13:16:49 [MgmSrvr] INFO     -- Node 2: OP[470]: Tab: 4 frag: 0 TC: 3 API:
5(0x8035)transid: 0x31c 0x3500500 op: SCAN state: InQueue
2006-10-09 13:16:49 [MgmSrvr] INFO     -- Node 2: End of operation dump

E.g dump all operations on node 2, from api node 5 using table 4
ndb_mgm> 2 dump 2350 1 5 0 4
2006-10-09 13:16:49 [MgmSrvr] INFO     -- Node 2: Starting dump of operations
2006-10-09 13:16:49 [MgmSrvr] INFO     -- Node 2: OP[470]: Tab: 4 frag: 0 TC: 3 API:
5(0x8035)transid: 0x31c 0x3500500 op: SCAN state: InQueue
2006-10-09 13:16:49 [MgmSrvr] INFO     -- Node 2: End of operation dump

E.g dump all operations on node 2, from api node 5
ndb_mgm> 2 dump 2350 1 5
2006-10-11 13:31:25 [MgmSrvr] INFO     -- Node 2: Starting dump of operations
2006-10-11 13:31:25 [MgmSrvr] INFO     -- Node 2: OP[3]: Tab: 3 frag: 1 TC: 2 API:
5(0x8035)transid: 0x3 0x200400 op: INSERT state: Prepared
2006-10-11 13:31:25 [MgmSrvr] INFO     -- Node 2: End of operation dump

E.g get primary key of this operation
ndb_mgm> 2 dump 2352 3
2006-10-11 13:31:31 [MgmSrvr] INFO     -- Node 2: OP[3]: transid: 0x3 0x200400 key: 0x2 

---

Documentation of how to match output to specific threads/ndb-objects

If you add this code to you api program:
  printf("MyNdb.getReference(): 0x%x\n", MyNdb.getReference());

The output will be:
MyNdb.getReference(): 0x80350005

The high 16 bit of this value corresponds to number in parentheses 

---

Documentation of the different states

Note: All states are not descibed, but only the "normal" ones

These are:
Transactions:
* Prepared
  TC is idle waiting for API to proceed
* Running
  TC is currently working on preparing operations
* Committing, Prepare to commit, Commit sent
  TC is committing
* Completing
  TC is completing (after commit, some cleanup is needed)
* Aborting
  TC is aborting transaction
* Scanning
  TC is scanning

Scan operations:
* WaitNextScan
  Scan is idle, waiting for API
* InQueue
  Scan has not started but is waiting in queue, for other scans to be finished

PK operations:
* In lock queue
  Operation is waiting on lock
* Running
  Operation is "running", i.e being prepared
* Prepared
  Operation is prepared holding appropriate lock, and waiting for commit/rollback

---

General comment about this feature.

The dump commands should normally not be used in "everyday" production, due to the
following
1) Testing of them is not as structured/complete as testing of "real" features
2) Data-transport (to cluster log) is not efficient (but plain text)

We have a specification on an interface to have a proper 
ndbapi cursor interface with SQL syntax.
But this will not be implemented shortly.