From: jonas
Date: December 21 2005 3:53pm
Subject: bk commit into 5.1 tree (jonas:1.1975)
List-Archive: http://lists.mysql.com/commits/329
Message-Id: <20051221155355.46B60211CB3@perch.ndb.mysql.com>
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
1.1975 05/12/21 16:53:50 jonas@stripped +1 -0
ndb - opt nr
add text document
storage/ndb/src/kernel/blocks/OptNR.txt
1.1 05/12/21 16:53:47 jonas@stripped +49 -0
New BitKeeper file ``storage/ndb/src/kernel/blocks/OptNR.txt''
storage/ndb/src/kernel/blocks/OptNR.txt
1.0 05/12/21 16:53:47 jonas@stripped +0 -0
BitKeeper file /home/jonas/src/51-ndb/storage/ndb/src/kernel/blocks/OptNR.txt
# 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/51-ndb
--- New file ---
+++ storage/ndb/src/kernel/blocks/OptNR.txt 05/12/21 16:53:47
*** Copy thread
Scan rowids with GCP > starting nodes GCP
Cases for different ROWID combinations
RI Primary Starting Result
1 A A Update A
2 B B* Delete B* + Insert B
3 C C* Delete C* + Delete C + Insert C
C
4 Deleted D Delete D
5 E Deleted Insert E
6 F Deleted Delete F + Insert F
F
7 Deleted Deleted Update GCP
*** Ordinary operations
Op Starting Result
Insert A@1 A@1 Update A
Insert A@1 A@2 Delete A@2, Insert A@1
Insert A@1 1 busy, A@2 Delete 1, Delete A@2, Insert A@1
Insert A@1 1 busy Delete 1, Insert A@1
Delete A@1 A@1 Delete A@1
Delete A@1 else noop
Update A@1 A@1 Update A
Update A@1 else noop
***
Rationale:
If copy has passed rowid,
then no ordinary operation should be a noop
If copy has not passed,
then it's ok to do a noop as copy will get there sooner or later
Copy may not end up in lock queue, as no lock is held on primary.
therefore ordinary ops must be noops when rowid missmatch
When not scanning in rowid order (e.g. disk order) one must
1 make a second pass in rowid order
- finding deletes and inserts (as 2)
2 mark all inserts "earlier" than current scan pos
so they will be found during second pass
Note: Dealloc is performed first on backup then on primary