89141d4b3a
Validate subrange reads in simulation ( #7597 )
...
* Add extra validation to special key space reads in simulation
* Fix bugs turned up by validating subrange reads
* Change to validateSpecialSubrangeRead
It is in general not safe to expect that a read from the special key
space returns the same results if performed again, since the
transaction may be being modified concurrently.
* Add comment
* Add comment
2022-07-21 14:42:08 -07:00
a71099471b
Update copyright header dates
2022-03-21 13:36:23 -07:00
abf73047ca
Enforce std:: specifier rather than using namespace
2021-09-16 19:40:28 -07:00
e918d20f68
Document "averaged" parameter of PerfMetric constructor
2021-08-29 15:38:21 -07:00
b9a22a61ef
Fix many -Wreorder-ctor warnings
2021-07-23 17:33:18 -07:00
5c2d7b6080
Create RangeResult type alias
2021-05-03 13:14:16 -07:00
df90cc89de
apply clang-format to *.c, *.cpp, *.h, *.hpp files
2021-03-10 10:18:07 -08:00
4669f837fa
Add uses of makeReference
2020-11-07 22:10:18 -08:00
012886a8d8
Fix Windows CMake build
2020-10-07 12:30:19 -07:00
7f0d14c8e4
Modernize/refactor workloads directory
2020-10-04 22:29:07 -07:00
bc412f39a6
Augment ReportConflictingKeys test to catch memory error
2020-07-24 23:31:00 +00:00
a03a3c297d
Add more detailed traces
2020-05-21 14:48:35 -07:00
8ab792d58b
Add assertions that results are empty if no conflicts happen
2020-05-15 16:34:43 -07:00
a65f767997
Using coinflip() to simplify the code
2020-05-15 16:34:43 -07:00
c6a09559ee
Allow multiple clients in report-conflicting-keys correctness test
2020-05-15 16:34:42 -07:00
2a6de93b92
add copyright information
2020-04-08 14:50:55 -07:00
20b2984841
fix issues according to andrew's comments
2020-04-08 12:43:25 -07:00
a93c0053ca
add two asserts
2020-04-03 19:09:12 -07:00
62627dd2ee
Fix a randomness bug and naming issue in TraceEvent
2020-03-25 00:55:40 -07:00
289487559d
Revert "Revert "Merge pull request #2257 from zjuLcg/report-conflicting-key""
...
This reverts commit 804fe1b22e
2020-03-24 18:11:15 -07:00
804fe1b22e
Revert "Merge pull request #2257 from zjuLcg/report-conflicting-key"
...
This reverts commit 648dc4a933487d131b38
2020-03-19 21:34:28 -07:00
9dc441c65a
clang-format
2020-03-13 15:43:01 -07:00
39a37531db
Fix issues according to Andrew's comments
2020-03-13 15:42:15 -07:00
c246f79d72
Update comments
2020-03-13 13:18:18 -07:00
a3b0dce3cd
Rename vars, update comments
2020-03-13 13:12:22 -07:00
8ee4fea3d3
clang-format
2020-03-13 12:54:12 -07:00
aef9b515de
Change the workload to a more controlled test like ConflictRange test
2020-03-13 12:42:28 -07:00
7118759dfa
Delete code to test resolvers' performance, simplify the workload to only test correctness
2020-03-13 01:48:55 -07:00
6f90228a0b
change to krmSetRangeCoalescing
2020-03-12 11:31:36 -07:00
c2f0c41c52
use krmSetRange
2020-03-11 23:12:38 -07:00
1a5b41157e
add test for native transaction object
2020-03-11 11:17:34 -07:00
3a98c691b6
Update comments
2020-03-04 11:42:19 -08:00
5386b4ecdf
Adding prefix to returned keys, keeping consistency with query range
2020-01-21 15:18:16 -08:00
72d39a31f1
Change to send back index of read_conflict_range not keys, which speeds up but fail to give narrowed keyrange
2020-01-15 10:21:51 -08:00
1cf3b5b807
Change to general prefix '\xff\xff/transaction/conflicting_keys/'
2020-01-13 20:54:16 -08:00
9a736dde8d
delete wait in workload when checking, add assert to make sure the getRange for conflicting keys happens locally
2020-01-10 18:01:17 -08:00
57fb28af2c
Explicitly set read-version and clear the whole keyspace to make sure the getRange happens locally
2020-01-07 13:54:33 -08:00
10719200c3
A hack way to call API through getRange("\xff\xff/conflicting_keys\<start_key>", "\xff\xff/conflicting_keys\<end_key>").
2020-01-06 11:22:11 -08:00
9dc79488a8
narrow the returned conflicting ranges
2019-12-06 16:21:19 -08:00
b376b947d5
Encode conflicting keys using base64.
2019-12-06 16:21:19 -08:00
eacfdf6da3
Add a simple workload, ReportConflictingKeysWorkload, to test correctness of the API and performance overhead added to the resovler.
2019-12-06 16:21:03 -08:00
Andrew Noyes