bzr commit into mysql-5.1-innodb branch (marko.makela:3421)

[marko.makela]

#At file:///home/marko/innobase/dev/mysql/5.1-innodb/ based on revid:marko.makela@strippedcrw4x4sfkk

 3421 Marko Mäkelä	2010-04-26
      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
      storage/innodb_plugin/lock/lock0lock.c
=== modified file 'storage/innobase/lock/lock0lock.c'
--- a/storage/innobase/lock/lock0lock.c	2010-02-03 01:57:32 +0000
+++ b/storage/innobase/lock/lock0lock.c	2010-04-26 13:10:29 +0000
@@ -4538,13 +4538,34 @@ lock_rec_queue_validate(
 					       rec, impl_trx));
 		}
 	}
-
+#if 0
 	if (index && !(index->type & DICT_CLUSTERED)) {
 
 		/* The kernel mutex may get released temporarily in the
 		next function call: we have to release lock table mutex
 		to obey the latching order */
 
+		/* 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);
 
@@ -4555,7 +4576,7 @@ lock_rec_queue_validate(
 					       rec, impl_trx));
 		}
 	}
-
+#endif
 	lock = lock_rec_get_first(rec);
 
 	while (lock) {

=== modified file 'storage/innodb_plugin/lock/lock0lock.c'
--- a/storage/innodb_plugin/lock/lock0lock.c	2010-02-20 16:45:41 +0000
+++ b/storage/innodb_plugin/lock/lock0lock.c	2010-04-26 13:10:29 +0000
@@ -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);

Attachment: [text/bzr-bundle] bzr/[e-mail]