The checkpoint expelling code added in Mad-Hatter can fail to expel an item from a Checkpoint if there's only 1 candidate item to expel.
This can result in increased memory usage (see
MB-37294), which is more significant for large Documents / small memory quotas.
(Separated out from
Difficult to precisely trigger this scenario in full-stack tests, however you want to attempt to end up with a Checkpoint as follows, and then have expelling be attempted:
- Two adjacent mutations (at seqnos 1001 and 1002).
- The the first mutation shares its seqno with the remainder of the items in the checkpoint (here with meta-items checkpoint_start & empty).
Note that checkpoint state can be examined via:
Any set regular workload under DGM (e.g. pillowfight) should trigger this.
Such checkpoints should allow all but the last item (1002) to be expelled:
No items are expelled.
|For Gerrit Dashboard: MB-37330|
|119650,3||MB-37330: Correct expelling logic for items with same seqno||mad-hatter||kv_engine||Status: MERGED||+2||+1|
|119663,1||MB-37330: Correct expelling logic for items with same seqno||master||kv_engine||Status: ABANDONED||0||0|
|119897,5||Merge remote-tracking branch 'couchbase/mad-hatter'||master||kv_engine||Status: MERGED||+2||+1|