[SERVER-3589] server downgrade doesn't handle new index version Created: 12/Aug/11  Updated: 11/Jul/16  Resolved: 17/Aug/11

Status: Closed
Project: Core Server
Component/s: Index Maintenance
Affects Version/s: 1.9.1
Fix Version/s: 1.8.3

Type: Bug Priority: Major - P3
Reporter: Chris Westin Assignee: Eliot Horowitz (Inactive)
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Tested on Vista 64


Issue Links:
Depends
Operating System: ALL
Participants:

 Description   

The docs and qa bug indicate that a downgrade should fail, or that at least operations against a newer index format should fail:
http://www.mongodb.org/display/DOCS/Index+Versions#IndexVersions-RollingBacktoMongoDB%3Cv2.0

Create a collection with an index on it and verify new index version format:

db = db.getSisterDB("qadb");

db.idx1.drop();
db.idx1.save(

{a:1, b:1}

);
db.idx1.ensureIndex(

{a:1, b:1}

);

var idxlist = db.idx1.getIndexes();
idxlist;
// note v:1 indexes

downloaded 1.8.2. start it on the same database files. mongod starts up normally.
I issued some queries, the last of which should use the index. Note that query does not return an error as specified in the docs, but it also doesn't return the correct result:

> use qadb
switched to db qadb
> db.idx1.find();

{ "_id" : ObjectId("4e445314fb3e65e39a74d26c"), "a" : 1, "b" : 1 }

> db.idx1.find(

{b:1}

);

{ "_id" : ObjectId("4e445314fb3e65e39a74d26c"), "a" : 1, "b" : 1 }

> db.idx1.find(

{a:1}

);
> db.idx1.getIndexes();
[
{
"v" : 1,
"key" :

{ "_id" : 1 }

,
"ns" : "qadb.idx1",
"name" : "id"
},
{
"v" : 1,
"key" :

{ "a" : 1, "b" : 1 }

,
"ns" : "qadb.idx1",
"name" : "a_1_b_1"
}
]
>



 Comments   
Comment by auto [ 17/Aug/11 ]

Author:

{u'login': u'erh', u'name': u'Eliot Horowitz', u'email': u'eliot@10gen.com'}

Message: better handling of new index versions SERVER-3589
Branch: v1.8
https://github.com/mongodb/mongo/commit/d4435681b510407cf2ba83f338a3a925efaeb1ec

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