Concurrency control and utilities for (key) constraints of a table #2699
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggest
2D9A
ions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR adds locking to the constraints stored for a table. Specifically a
_constraint_mutex
is added to a table. To acquire this mutexacquire_constraints_modify_mutex
can be used.To avoid redundant validation or invalidation of key constraints that are already known to be valid or invalid, two new timestamp attributes are introduced:
_last_validated_on
and_last_invalidated_on
. These store the CommitID of the most recent validation or invalidation.With this data, we can determine whether a
TableKeyConstraint
is still confidently valid or invalid by comparing the stored CommitIDs with those of the table’s chunks. This logic is implemented in two new methods:is_constraint_confidently_valid
andis_constraint_confidently_invalid
, located inconstraint_utils.cpp
.As these methods are not yet used in the
UCCDiscoveryPlugin
, we can only add tests in the following locations:src/test/lib/concurrency/stress_test.cpp
src/test/lib/storage/constraints/constraint_utils_test.cpp