Repository navigation
[Bug]: Verify if range split acquire all lock can be aborted #201
Description
Now we abort range partitioned tx on range lock conflict to avoid deadlock between regular txs and range split txs.
This causes many txs abort with RW_CONFLICT which is confusing to user. We should rely on deadlock abort to abort txs when there is actually a deadlock rather than just abort every regular tx if its holding a range read lock.
Verify if aborting range split still works.
Remove the abort logic in regular tx on rw conflict.
acquire lock fail on range lock should trigger deadlock check instantly.
NOTE: acquire write all on range lock will block on lock acquisition if there're ongoing read txs. But regular read req on range entry now backs off when acquire lock fails. So deadlock check will never trigger in this case since there is no deadlock loop.
We should make range read block on failure too, and trigger a deadlock check instantly when it fails to acquire range read lock, but make sure don't spam deadlock check too much as it is very expensive. Do it like once per second in this case.
Activity
githubzilla commentedon Dec 10, 2025
githubzilla commentedon Jan 30, 2026
Start rework.....
githubzilla commentedon Feb 2, 2026
Rework this issue after found the PR cause CKPT stuck.
githubzilla commentedon Feb 5, 2026
Fix ready, running CI test
githubzilla commentedon Feb 6, 2026
The previous implementation did not handle the condition when range ReadCc is resumed after it was blocked by the write lock on the same range, the range can be splitted before ReadCc is resumed, and the ReadCc has to add lock on a new range and corresponding bucket, but the locks on the previous range and bucket acquired in last round need to be released, otherwise it will block the checkpoint TS to be advanced.
Release the locks on the previous range and bucket acquired in last round if the range is changed
githubzilla commentedon Feb 6, 2026