PrimaryIndexOperationTracker does not protect uncommitted data from going to disk

[GoogleCodeExporter]

What steps will reproduce the problem?
The following incorrect scenario is possible in the current codebase:

2 inserters and 1 searcher. All of them were able to grab the lsm components 
that they need.

The first inserter causes the mutable component to be full and changes its 
state to READABLE_UNWRITABLE and leaves. The searcher comes in and see the 
number of active ops to be zero (assuming the first inserter's commit log made 
it to disk) and also find the mutable component to be full; thus, it schedules 
a flush. Meanwhile the second inserter comes in and pumps the active ops 
counter. Now the flush will go through without paying attention to the counter 
anymore. As soon as the second inserter leaves the mutable component, the flush 
will proceed causing uncommitted data to go to disk.

Original issue reported on code.google.com by salsuba...@gmail.com on 29 Jul 2013 at 8:18

[GoogleCodeExporter]

How did the second inserter get in if the state was READABLE_UNWRITABLE?

Original comment by zheilb...@gmail.com on 29 Jul 2013 at 8:45

[GoogleCodeExporter]

The are running concurrently. Suppose the second inserter has reached line 96 
in LSMHarness.

Original comment by salsuba...@gmail.com on 29 Jul 2013 at 11:22

[GoogleCodeExporter]

Original comment by salsuba...@gmail.com on 30 Jul 2013 at 7:54

• Changed state: FixedInBranch

[GoogleCodeExporter]

Original comment by salsuba...@gmail.com on 23 Aug 2013 at 5:34

• Changed state: Fixed