diff options
author | Vasil Dimov <vasil.dimov@oracle.com> | 2010-05-04 13:19:37 +0300 |
---|---|---|
committer | Vasil Dimov <vasil.dimov@oracle.com> | 2010-05-04 13:19:37 +0300 |
commit | 6cd860afa6e26dda7987b4e6e03d904ecdeb0d93 (patch) | |
tree | 478823a3380412ccb9d3fe5db2d0e37c6a80936b /storage/innobase/lock/lock0lock.c | |
parent | 126f35308e15db25418ac392072ac75c91ea608e (diff) | |
download | mariadb-git-6cd860afa6e26dda7987b4e6e03d904ecdeb0d93.tar.gz |
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
------------------------------------------------------------
Diffstat (limited to 'storage/innobase/lock/lock0lock.c')
-rw-r--r-- | storage/innobase/lock/lock0lock.c | 23 |
1 files changed, 23 insertions, 0 deletions
diff --git a/storage/innobase/lock/lock0lock.c b/storage/innobase/lock/lock0lock.c index d5fff572aee..3c740df97ff 100644 --- a/storage/innobase/lock/lock0lock.c +++ b/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); |