You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
sql: only use side-effect splitter if locking durability = guaranteed
The span splitter has an optimization to skip reading column families
whose columns are contained entirely in the index key. In #116170 we
added a flag to the span splitter to ignore this optimization when the
read has a side-effect (i.e. it's a locking read).
The intention of #116170 was to ensure that SELECT FOR UPDATE statements
under Read Committed isolation lock all requested column families. But
the span splitter flag also applies to the implicit for-update locking
added to mutation statements. This was not intentional. The implicit
for-update locking added to mutation statements is not needed for
correctness, but is supposed to be a lightweight optimization to prevent
retries of racing write-write conflicts. The implicit for-update locking
is already not durable. It's fine if it does not lock every requested
column family.
This commit changes the decision about whether to use the span splitter
optimization to depend on the locking durability, rather than the
isolation level. This extends the meaning of locking durability
slightly, but I think it fits within the semantics of best effort = the
requested lock might not actually be held.
This should fix the YCSB regression under Read Committed isolation.
Fixes: #143138
Release note: None
0 commit comments