[SERVER-17562] Invariant failure: s->commit_transaction(s, NULL) resulted in status BadValue 22 Created: 12/Mar/15 Updated: 19/Sep/15 Resolved: 27/Mar/15 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Storage, WiredTiger |
| Affects Version/s: | 3.1.0 |
| Fix Version/s: | 3.0.2, 3.1.1 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Kaloian Manassiev | Assignee: | Geert Bosch |
| 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: | |||||||||
| Sprint: | Quint Iteration 3.1.1 | ||||||||
| Participants: | |||||||||
| Linked BF Score: | 0 | ||||||||
| Description |
|
One of the MCI parallel suites failed with the invariant violation below (the call stack has been demangled). The full logs are attached.
|
| Comments |
| Comment by Geert Bosch [ 02/Apr/15 ] |
|
Yes, that would be good, even though we've worked around this issue in the integration layer now. -Geert |
| Comment by Michael Cahill (Inactive) [ 02/Apr/15 ] |
|
This is arguably a case of WiredTiger being too strict. We track whether any operation has "failed" during a transaction, with a fairly broad definition of failure. If an operation fails, any attempt to call WT_SESSION::commit_transaction will cause a rollback and return an error. In the case of read-only transactions, this is a non-issue, because rollback and commit are equivalent. I'll open an issue to review this, it seems like we should be able to relax the restriction and allow commit after failures in read-only transactions. |
| Comment by Geert Bosch [ 01/Apr/15 ] |
|
Nothing, as there shouldn't be any writes. There will never be an active write transaction. Essentially, the commitAndRestart function is about the read side of the transaction. It is OK for the storage engine at this point to drop any snapshots or other resources associated with the given recoveryUnit and have the next read reflect new updates etc. -Geert |
| Comment by Igor Canadi [ 01/Apr/15 ] |
|
So mongo-rocks should also rollback transaction in this method? What can go wrong if we try to commit? From my understanding, commitAndRestart() should never be called with active write transaction (because _depth == 0), right? Under which conditions can there be active write transaction during commitAndRestart()? |
| Comment by Geert Bosch [ 31/Mar/15 ] |
|
Yes, sure. The answer is that the method is badly named. We'll be renaming it. -Geert |
| Comment by Igor Canadi [ 31/Mar/15 ] |
|
Geert can you please provide more context here? Method name is commitAndRestart(), so it's a bit counter-intuitive that correct behavior is to rollback the transaction. |
| Comment by Githook User [ 30/Mar/15 ] |
|
Author: {u'username': u'GeertBosch', u'name': u'Geert Bosch', u'email': u'geert@mongodb.com'}Message: (cherry picked from commit bbe95e94bc7231a0b06c395a52c6575d7d23e03e) |
| Comment by Githook User [ 25/Mar/15 ] |
|
Author: {u'username': u'GeertBosch', u'name': u'Geert Bosch', u'email': u'geert@mongodb.com'}Message: |