MyRocks - gap lock error logic does not account for ISO mode

Bug #1658843 reported by George Ormond Lorch III on 2017-01-24
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Percona Server moved to https://jira.percona.com/projects/PS
Status tracked in 5.7
5.6
Fix Released
Medium
George Ormond Lorch III
5.7
Fix Released
Medium
George Ormond Lorch III

Bug Description

https://jira.percona.com/browse/MYR-35

Our gap lock error implementation (from MYR-15) currently is not taking into account the current ISO mode. This logic should be changed to amend an additional condition before deciding to error to the client:
{code:java}
&& thd_tx_isolation(thd) >= ISO_REPEATABLE_READ
{code}
Therefore, if the ISO is <= READ COMMITTED, the gap lock error will not be raised in the condition of a gap lock, but as the ISO mode moves any further north in the consistency scale to REPEATABLE READ or SERIALIZABLE, then the gap lock error will be raised when conditions are met.

We will need to clearly document this behavior and the suggested default ISO mode of READ COMMITTED with MyRocks use cases. We will also need to update the MyRocks mtr suites to explicitly test ISO modes against the gap lock error, change the default ISO mode for the suites to READ COMMITTED, and re-word the error message.

This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers