MYR-103 : rocksdb.gap_lock_error fails #1519
Conversation
george-lorch
commented
Mar 16, 2017
•
george-lorch
commented
- Test components were still creating tables w/o explicit engine specifier.
- Fixed remaining CREATE TABLE statements and re-recorded affected tests.
george-lorch
force-pushed
the
ps-5.6-MYR-103
branch
from
995075f
to
bdcef48
Compare
george-lorch
changed the title
| @@ -71,7 +71,6 @@ insert into u1 values (1,2,1,1) on duplicate key update c4=10; | |||
| commit; | |||
| begin; | |||
| select * from u1 where c3=1 and c1 = 1 for update; | |||
| --error ER_UNKNOWN_ERROR | |||
| select * from u1 where c3=1 for update; | |||
There was a problem hiding this comment.
But this is not a point select, is it? c3 is only an initial part of an unique column, and as such, this query might return a range of rows
There was a problem hiding this comment.
I don't believe so, the query should lock and return specific rows but not a true range of rows and gaps between rows. It should not be locking any space in between keys which would trigger the gap lock violation. So true, it is not a single row point select, but it is not a gap or range select either.
What I am curious about is how this behavior changed/test started failing without detection at the time of the cause. I suspect something in one of the massive upstream merges got by without me noticing due to the noise of continuous mass failures of mtr cases. I'm tempted to start a history bisection to see if I can figure at what point this changed from my initial work on MYR-15 and later work in MYR-35. i.e. why did this pass (incorrectly) before and not now?
There was a problem hiding this comment.
OK, please find out
There was a problem hiding this comment.
OK, here is the real problem, this table, u1, is not created with an engine specifier. I reported/noticed this issue while switching from the custom mtr incantation that specifies default_storage_engine to the standard mtr incantation that does not and dis not make the mental connection of that change over to where this failure started appearing. The test is broken in that this specific table is not properly created with the engine specifier.
That said, looking back at the logic, yes, your original statement is correct, I read through the !using_full_primary_key too fast, which is the first condition to be met for a gap lock. So this change is not the correct fix for the issue.
- Test components were still creating tables w/o explicit engine specifier. - Fixed remaining CREATE TABLE statements and re-recorded affected tests.
george-lorch
force-pushed
the
ps-5.6-MYR-103
branch
from
bdcef48
to
81ba879
Compare
|
Pushed correct changes, changed PR message and now that we are into common mt code added jenkins job to prove that other tests do not break as a result |
