Currently, validation is performed on a single thread by running a sequence of R/W operations (without any overlap between any of the operations), while the benchmark uses concurrent operations (but no validation is performed). This makes detecting concurrency bugs impossible. So far, this was not a serious limitation as the inserts were not too contentious and were unlikely to corrupt the database. However, with the introduction of delete operations, it will be important to perform a more thorough validation sequence.
A good middle ground would be to run a concurrent workload followed by a sequence of read-only (potentially concurrent) operations.
Technically, this seems to be relatively easy to do, as it's essentially a concatenation of a "benchmark" and a "create validation parameters" / "validate" phase.
Currently, validation is performed on a single thread by running a sequence of R/W operations (without any overlap between any of the operations), while the benchmark uses concurrent operations (but no validation is performed). This makes detecting concurrency bugs impossible. So far, this was not a serious limitation as the inserts were not too contentious and were unlikely to corrupt the database. However, with the introduction of delete operations, it will be important to perform a more thorough validation sequence.
A good middle ground would be to run a concurrent workload followed by a sequence of read-only (potentially concurrent) operations.
Technically, this seems to be relatively easy to do, as it's essentially a concatenation of a "benchmark" and a "create validation parameters" / "validate" phase.