Force oldest locks into shard locks due to range limits - #11329
Conversation
ec2cd8c to
bf7f1b2
Compare
bf7f1b2 to
560706e
Compare
|
⚪ DetailsTest history | Ya make output | Test bloat
⚪ Test history | Ya make output | Test bloat | Test bloat
🟢
*please be aware that the difference is based on comparing your commit and the last completed build from the post-commit, check comparation |
|
⚪ Test history | Ya make output | Test bloat
🟢
*please be aware that the difference is based on comparing your commit and the last completed build from the post-commit, check comparation |
560706e to
4d95415
Compare
|
⚪ DetailsTest history | Ya make output | Test bloat
⚪ Test history | Ya make output | Test bloat | Test bloat
🟢
*please be aware that the difference is based on comparing your commit and the last completed build from the post-commit, check comparation |
|
⚪ Test history | Ya make output | Test bloat
🟢
*please be aware that the difference is based on comparing your commit and the last completed build from the post-commit, check comparation |
2 participants
Changelog entry
Force oldest (not newest) locks into shard locks due to range limits.
Changelog category
Additional information
Historically datashards forced new locks into whole shard locks when reaching limits on the number of ranges (which incidentally have been the same as the number of locks), which is counter intuitive in the presence of long running read-only transactions that perform joins (and hence lots of point reads), causing very short read-write transactions to repeatedly fail due to unrelated conflicts in the presence of older and wider locks. We prefer forcing oldest locks into shard locks now, which are more likely to break due to conflicts anyway, and may not even cause read-only transactions to fail when they do. Newer locks are now exact (as long as they are small enough), with a significant increase to the maximum number of ranges we support (up to 1M total ranges and 50K per-lock ranges, instead of the previous 16K).
Fixes #10725.