[SERVER-15187] prototype bdb storage engine Created: 09/Sep/14  Updated: 25/Oct/14  Resolved: 08/Oct/14

Status: Closed
Project: Core Server
Component/s: Storage
Affects Version/s: None
Fix Version/s: 2.7.8

Type: New Feature Priority: Major - P3
Reporter: Eliot Horowitz (Inactive) Assignee: Eliot Horowitz (Inactive)
Resolution: Done Votes: 0
Labels: pull-request
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Tested
Backwards Compatibility: Fully Compatible
Participants:

 Description   

For testing out transaction interface.



 Comments   
Comment by Ian Whalen (Inactive) [ 08/Oct/14 ]

done as an exercise to test the storage engine API. Not meant for production.

Comment by Githook User [ 22/Sep/14 ]

Author:

{u'username': u'dpercy', u'name': u'David Percy', u'email': u'david.percy@mongodb.com'}

Message: SERVER-15187 Fix lifetime problem with stashed RecoveryUnit

When a ClientCursor owns a RecoveryUnit, it should destroy its
PlanExecutor before the RecoveryUnit, because storage engines in
general expect the RecoveryUnit to outlive cursors.

In particular, this fixes a bug where BDBCursor's destructor would fail
to close its Dbc* since the DbTxn* in BDBRecoveryUnit was already gone.

Closes #789

Signed-off-by: Benety Goh <benety@mongodb.com>
Branch: master
https://github.com/mongodb/mongo/commit/532b1595c96eb492f7a9813b855d28919a20dd78

Comment by Githook User [ 18/Sep/14 ]

Author:

{u'username': u'dpercy', u'name': u'David Percy', u'email': u'david.percy@mongodb.com'}

Message: SERVER-15187 Update saved OperationContext in all PlanStages

Every stage that has a field of type OperationContext*
should be updating it when ::restoreState(OperationContext*) is called.
Otherwise it is retaining a reference to deleted memory.

This bug hasn't surfaced before because:
1. the OperationContext used to be stack allocated, so it would have the
same address every time
2. mmapv1 doesn't always need to dereference the OperationContext

Closes #781

Signed-off-by: Benety Goh <benety@mongodb.com>
Branch: master
https://github.com/mongodb/mongo/commit/ccacca83853931e2d03c8670c1745dfac515e119

Comment by Githook User [ 17/Sep/14 ]

Author:

{u'username': u'dpercy', u'name': u'David Percy', u'email': u'david.percy@mongodb.com'}

Message: SERVER-15187 Fix compile error in RocksDB

An earlier commit, 0b167545b6e6a0f8c193d1aab8e094256fc8fa16,
added a parameter in the storage engine interface, but I missed
some uses in RocksDB.

Closes #778

Signed-off-by: Benety Goh <benety@mongodb.com>
Branch: master
https://github.com/mongodb/mongo/commit/5b5decd541a6449ec4641992ae0ecb89207a0dc0

Comment by Michael Cahill [ 17/Sep/14 ]

Is there more to this issue than that commit? I'm still seeing a bogus OperationContext when running `batch_size.js` among other tests:

#2  0x0000000001051749 in mongo::Collection::docFor (this=0x7ffff6ce1100, txn=0x7ffff6dad220, loc=...)
    at src/mongo/db/catalog/collection.cpp:161
#3  0x000000000114e857 in mongo::CollectionScan::work (this=0x7ffff74754c0, out=0x7fffebac9370)
    at src/mongo/db/exec/collection_scan.cpp:108
#4  0x0000000001367a0b in mongo::PlanExecutor::getNext (this=0x7ffff74ddf90, objOut=0x7fffebac94f0, dlOut=0x0)
    at src/mongo/db/query/plan_executor.cpp:132
#5  0x000000000134781c in mongo::newGetMore (txn=0x7ffff6c8a300, ns=0x7ffff05fa4b4 "test.jstests_batch_size", ntoreturn=2,
    cursorid=10344099904, curop=..., pass=0, exhaust=@0x7fffebac9646: false, isCursorAuthorized=0x7fffebac96d0)
    at src/mongo/db/query/new_find.cpp:243

Note that txn=0x7ffff6c8a300 in frame 5 != txn=0x7ffff6dad220 in frame 2.

Comment by Githook User [ 16/Sep/14 ]

Author:

{u'username': u'dpercy', u'name': u'David Percy', u'email': u'david.percy@mongodb.com'}

Message: SERVER-15187 Add OperationContext parameter to restoreState

Storage engines might need the current OperationContext to restore their
state.

For example, BDBRecordIterator needs access to the current underlying
transaction to recreate an underlying cursor. Having the BDBRecordIterator
save a pointer to the OperationContext it was created with won't work,
because the OperationContext is destroyed and a new one created between
saveState and restoreState.
Branch: master
https://github.com/mongodb/mongo/commit/0b167545b6e6a0f8c193d1aab8e094256fc8fa16

Generated at Thu Feb 08 03:37:13 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.