Details
-
Bug
-
Resolution: Unresolved
-
Major
-
7.6.0, 7.0.0, 7.1.0, 7.2.0, 7.2.1, 7.2.4, 7.2.2, 7.2.3, 7.2.5, 7.6.2, 7.2.6, 7.6.1
-
Untriaged
-
0
-
No
Description
This bug affects Ephemeral buckets only.
When a backfill is created, it should check that the purgeSeqno < startSeqno, to ensure that the client will not miss deletes.
Ephemeral buckets store changes in a linked list (the sequence list). Ranges of changes from this list can be locked (a read range) when they are needed for backfills.
In the backfill initialisation code in DCPBackfillMemoryBuffered::create, we create a read range (makeRangeIterator). This prevents tombstone purging. Then we check purgeSeqno < startSeqno.
When we do, we read the purgeSeqno from the VBucket object (VBucket::purgeSeqno), not from the LinkedList::getHighestPurgedDeletedSeqno and this is where the race can happen.
When tombstone purging occurs in EphemeralVBucket::purgeStaleItems, we call LinkedList::purgeTombstones(), which operates under the sequence list lock, but the update of the VBucket::purgeSeqno is not synchronised with that.
The backfill create can see the old purgeSeqno in this instance, and allow a backfill to be created which will miss deletes.