[SERVER-17119] Verify fails during AND_HASH query stage's readFirstChild Created: 29/Jan/15 Updated: 18/Sep/15 Resolved: 30/Mar/15 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Concurrency, Storage, WiredTiger |
| Affects Version/s: | 3.0.0-rc7 |
| Fix Version/s: | 3.0.2, 3.1.1 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Charlie Swanson | Assignee: | David Storch |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
|
||||||||||||
| Issue Links: |
|
||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||
| Operating System: | ALL | ||||||||||||
| Backport Completed: | |||||||||||||
| Steps To Reproduce: | Happens every time you run fsm_all with the workloads in the patch on MCI. If you don't want to run all of them, it should reproduce with just the yield_and_hash.js workload. |
||||||||||||
| Sprint: | Quint Iteration 3.1.1 | ||||||||||||
| Participants: | |||||||||||||
| Description |
|
Error occurs while running an FSM test which intersperses yielding an AND_HASH queries with updates/removes. Logs linked, important part of logs here:
|
| Comments |
| Comment by Githook User [ 31/Mar/15 ] |
|
Author: {u'username': u'dstorch', u'name': u'David Storch', u'email': u'david.storch@10gen.com'}Message: (cherry picked from commit 20cc174108c3ecf5040ebd64655b0cf39804e886) |
| Comment by Githook User [ 31/Mar/15 ] |
|
Author: {u'username': u'dstorch', u'name': u'David Storch', u'email': u'david.storch@10gen.com'}Message: |
| Comment by Githook User [ 30/Mar/15 ] |
|
Author: {u'username': u'dstorch', u'name': u'David Storch', u'email': u'david.storch@10gen.com'}Message: Since WT does not issue invalidations, docs will not be removed from the hash table when they (cherry picked from commit 36240ff99233a3f454bbd914fc691f5598283f10) |
| Comment by Githook User [ 30/Mar/15 ] |
|
Author: {u'username': u'dstorch', u'name': u'David Storch', u'email': u'david.storch@10gen.com'}Message: Since WT does not issue invalidations, docs will not be removed from the hash table when they |
| Comment by David Storch [ 29/Jan/15 ] |
|
The AND_HASH stage is reading results from its first child index scan and hashing these results based on their RecordId. The particular invariant that trips is ensuring that the RecordId from the child has not been seen yet, i.e. that the child index scan did not give us back a duplicate RecordId. However, it is possible to get a duplicate RecordId back when running a server configured the WiredTiger storage engine. Consider this scenario:
This is impossible in MMAP v1 due to the invalidation system, but invalidation notifications for updated RecordIds are not used with WiredTiger. |