bk commit into 5.0 tree (heikki:1.1821)

[Heikki Tuuri]

Below is the list of changes that have just been committed into a local
5.0 repository of heikki. When heikki 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.1821 05/04/13 16:49:28 heikki@stripped +1 -0
  row0sel.c:
    Fix the patch of Jan to optimize next-key locking in searches of type 'primary key >= some value'

  innobase/row/row0sel.c
    1.85 05/04/13 16:49:09 heikki@stripped +16 -9
    Fix the patch of Jan to optimize next-key locking in searches of type 'primary key >= some value'

# 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:	heikki
# Host:	hundin.mysql.fi
# Root:	/home/heikki/mysql-5.0

--- 1.84/innobase/row/row0sel.c	Wed Apr 13 12:06:41 2005
+++ 1.85/innobase/row/row0sel.c	Wed Apr 13 16:49:09 2005
@@ -3686,16 +3686,23 @@
  			}
 		}
 
-		/* If a constant search tuple is found directly from 
-		the cluster index we lock only a record. 
-		For example: WHERE a >= 100, where a is primary key */
+		/* If we are doing a 'greater or equal than a primary key
+		value' search from a clustered index, and we find a record
+		that has that exact primary key value, then there is no need
+		to lock the gap before the record, because no insert in the
+		gap can be in our search range. That is, no phantom row can
+		appear that way.
 
-		if(index == clust_index &&
-				match_mode == ROW_SEL_OPEN_CURSOR &&
-				mode == PAGE_CUR_GE &&
-				dtuple_get_n_fields_cmp(search_tuple)
-				== dict_index_get_n_unique(index) &&
-				!cmp_dtuple_rec(search_tuple, rec, offsets)) {
+		An example: if col1 is the primary key, the search is WHERE
+		col1 >= 100, and we find a record where col1 = 100, then no
+		need to lock the gap before that record. */
+
+		if (index == clust_index
+		    && mode == PAGE_CUR_GE
+		    && direction == 0
+		    && dtuple_get_n_fields_cmp(search_tuple)
+		       == dict_index_get_n_unique(index)
+		    && 0 == cmp_dtuple_rec(search_tuple, rec, offsets)) {
 
 			lock_type = LOCK_REC_NOT_GAP;
 		}