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