#At file:///C:/Work/bzr/Merge/mysql-6.0-falcon-team/ based on revid:kevin.lewis@stripped
2718 Kevin Lewis 2009-06-03
Bug#44911 - More follow-on changes.
This assures that there will not be a infinite loop in the case where a lock record is returned from Table::fetch and the transaction becomes CommittedVisible soon after. This should only occur once. The next time, it has to be a different lock record. If the same record is read again, something is fataly wrong. It happened once while I was making some changes for 43344 because of a mistake. So instead of looping infinitely reading the same record, this patch will issue a fatal error.
=== modified file 'storage/falcon/Table.cpp'
--- a/storage/falcon/Table.cpp 2009-06-03 20:49:27 +0000
+++ b/storage/falcon/Table.cpp 2009-06-03 21:01:11 +0000
@@ -3498,6 +3498,7 @@ Record* Table::fetchForUpdate(Transactio
// Find the record that will be locked
int recordNumber = source->recordNumber;
+ Record* prevSource = NULL;
// If we already have this locked or updated, get the active version
@@ -3555,7 +3556,18 @@ Record* Table::fetchForUpdate(Transactio
+ // A lock record may heve been read above, and before we called getRelativeState,
+ // the transactino may have committed a change. It could be visible for
+ // read committed and write committed isolations. But if the same lock record
+ // is read again, it could cause a hang and it should not ever happen.
+ // So prevent an unlikely hang with a FATAL message.
+ if (prevSource == source)
+ FATAL("Table::fetchForUpdate found a committed visible lock record.");
break; // need to re-fetch the base record
@@ -3605,6 +3617,7 @@ Record* Table::fetchForUpdate(Transactio
throw SQLError(RUNTIME_ERROR, "unexpected transaction state %d", state);
+ prevSource = source; // Don't ever folow this pointer!
source = fetch(recordNumber);
Attachment: [text/bzr-bundle] email@example.com
|• bzr commit into mysql-6.0-falcon-team branch (kevin.lewis:2718)Bug#44911||Kevin Lewis||3 Jun|