Merge from mysql-5.1-innodb:

  ------------------------------------------------------------
  revno: 3421
  revision-id: marko.makela@oracle.com-20100426131029-1ffja69h6n88q6bo
  parent: marko.makela@oracle.com-20100426112609-f7lgl8crw4x4sfkk
  committer: Marko M?kel? <marko.makela@oracle.com>
  branch nick: 5.1-innodb
  timestamp: Mon 2010-04-26 16:10:29 +0300
  message:
    lock_rec_queue_validate(): Disable a bogus check that
    a transaction that holds a lock on a clustered index record
    also holds a lock on the secondary index record.
  modified:
    storage/innobase/lock/lock0lock.c 2@cee13dc7-1704-0410-992b-c9b4543f1246:trunk%2Flock%2Flock0lock.c
    storage/innodb_plugin/lock/lock0lock.c 2@16c675df-0fcb-4bc9-8058-dcc011a37293:trunk%2Flock%2Flock0lock.c
  ------------------------------------------------------------

storage/innobase/lock/lock0lock.c

@@ -4710,6 +4710,7 @@ lock_rec_queue_validate(
 			ut_a(lock_rec_has_expl(LOCK_X | LOCK_REC_NOT_GAP,
 					       block, heap_no, impl_trx));
 		}
+#if 0
 	} else {
 
 		/* The kernel mutex may get released temporarily in the
@@ -4720,6 +4721,27 @@ lock_rec_queue_validate(
 		(fil_space_t::latch), the following check WILL break
 		latching order and may cause a deadlock of threads. */
 
+		/* NOTE: This is a bogus check that would fail in the
+		following case: Our transaction is updating a
+		row. After it has updated the clustered index record,
+		it goes to a secondary index record and finds someone
+		else holding an explicit S- or X-lock on that
+		secondary index record, presumably from a locking
+		read. Our transaction cannot update the secondary
+		index immediately, but places a waiting X-lock request
+		on the secondary index record. There is nothing
+		illegal in this. The assertion is simply too strong. */
+
+		/* From the locking point of view, each secondary
+		index is a separate table. A lock that is held on
+		secondary index rec does not give any rights to modify
+		or read the clustered index rec. Therefore, we can
+		think of the sec index as a separate 'table' from the
+		clust index 'table'. Conversely, a transaction that
+		has acquired a lock on and modified a clustered index
+		record may need to wait for a lock on the
+		corresponding record in a secondary index. */
+
 		impl_trx = lock_sec_rec_some_has_impl_off_kernel(
 			rec, index, offsets);
 
@@ -4730,6 +4752,7 @@ lock_rec_queue_validate(
 			ut_a(lock_rec_has_expl(LOCK_X | LOCK_REC_NOT_GAP,
 					       block, heap_no, impl_trx));
 		}
+#endif
 	}
 
 	lock = lock_rec_get_first(block, heap_no);