Time-series measurement deletes will perform a replacement-style update where they will replace the old bucket with a new bucket that only has the remaining, unaffected buckets. As part of creating this new bucket, the bucket max and min time are recalculated based on the remaining measurements. This means that if the measurements remaining in a bucket are all later in time than the earliest measurement in the bucket, the minTime will be updated.
However, the process of archiving buckets and reopening archived buckets depends on the minTime of a bucket never changing. When we archive a bucket we emplace it into the set of archivedBuckets with the minTime at that point as the key. If a measurement delete is performed on an archived bucket, and then later we reopen this bucket for more inserts, we will try to remove it from the set of archived buckets based on the minTime - but the minTime will have been changed, so we cannot find it and the bucket remains in the set.
Because it remains in the set, another thread can come along and close the archived bucket as part of the effort to get under the memory usage threshold. This removes the bucket's state from the bucketStateRegistry.
Then, when the thread that reopened the bucket to insert into it goes to prepare the commit/finish the write, it will invariant because the bucket's state will no longer be tracked in the bucket state registry.
- is related to
-
SERVER-98272 Create remediation for if the timestamp embedded in the bucket's ID does not match the control.min timestamp
- Open