Details
-
Bug
-
Resolution: Fixed
-
Critical
-
4.6.4, 5.1.0, 5.5.0
-
Untriaged
-
Unknown
Description
The following sequence demonstrates the issue (this has been performed via a unit-test)
- Create DCP and stream from vb0
- store into vb0 k1,k2,k3,k4 and k5
- stream all items, client knows about k1,k2,k3,k4 and k5
- delete k3 and k4 (we have to delete a minimum of 2 items because compaction never purges a delete if its the last seqno)
- run compaction - k3 tombstone is purged
- stream is slow... so we drop its cursor and go to backfill mode
- backfill finds delete(k4)
- client streams all items available and gets delete(k4)
Database has k1,k2,k5
Client has k1,k2,k3,k5
The cursor drop backfill was allowed to go beyond the purge-seqno, a normal stream request with backfill would be a rollback situation.
Attachments
Issue Links
For Gerrit Dashboard: MB-29480 | ||||||
---|---|---|---|---|---|---|
# | Subject | Branch | Project | Status | CR | V |
93537,2 | MB-29480: Create a unit-test which demonstrates the MB | master | kv_engine | Status: ABANDONED | -1 | -1 |
93690,8 | MB-29480, MB-29512: Fail backfills that go below purge-seqno | vulcan | kv_engine | Status: MERGED | +2 | +1 |
93994,1 | Merge branch 'vulcan' into 'master' | master | kv_engine | Status: MERGED | +2 | +1 |