bk commit into 5.1 tree (jonas:1.1975)

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