[SERVER-27464] Server allows creation of duplicate indexes Created: 19/Dec/16  Updated: 09/Jan/24

Status: Backlog
Project: Core Server
Component/s: Querying
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: David Storch Assignee: Backlog - Query Optimization
Resolution: Unresolved Votes: 1
Labels: indexv3, query-44-grooming
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
is duplicated by SERVER-36253 partialFilterExpression in partial in... Closed
Related
related to SERVER-78199 btree index check, avoid create dupli... Closed
related to SERVER-84667 index check, avoid create duplicate b... Closed
Assigned Teams:
Query Optimization
Operating System: ALL
Participants:
Case:

 Description   

If a request to build an index is delivered to the server, but that index already exists, the expected behavior is for the server to indicate to the client that the index already exists rather than building a duplicate index:

> db.c.drop()
true
> db.c.createIndex({a: 1}, {name: "index1"})
{
	"createdCollectionAutomatically" : true,
	"numIndexesBefore" : 1,
	"numIndexesAfter" : 2,
	"ok" : 1
}
> db.c.createIndex({a: 1}, {name: "index2"})
{
	"createdCollectionAutomatically" : false,
	"numIndexesBefore" : 2,
	"numIndexesAfter" : 2,
	"note" : "all indexes already exist",
	"ok" : 1
}

Note that the number of indexes before and after are reported as the same in the second invocation of the createIndex command. This is true when the indexes are semantically equivalent (i.e. have the same key pattern and the same collation) even if they are named differently.

This rule is broken if the equivalent index key patterns are "spelled" differently:

> db.c.drop()
true
> db.c.createIndex({a: 1}, {name: "index1"})
{
	"createdCollectionAutomatically" : true,
	"numIndexesBefore" : 1,
	"numIndexesAfter" : 2,
	"ok" : 1
}
> db.c.createIndex({a: 2}, {name: "index2"})
{
	"createdCollectionAutomatically" : false,
	"numIndexesBefore" : 2,
	"numIndexesAfter" : 3,
	"ok" : 1
}

This time, numIndexesAfter > numIndexesBefore for the second index build request. The server currently accepts any positive number to indicate that a field should be indexed ascending and any negative number to indicate that a field should be indexed descending, but these different spellings are not normalized properly.



 Comments   
Comment by Ian Whalen (Inactive) [ 03/Aug/18 ]

Both this and SERVER-36253 are separate manifestations of the fact that we do BSON comparison to determine whether two index specs are the same.

Comment by Asya Kamsky [ 18/May/18 ]

We should disallow anything other than 1 or -1 in the value field.  It will be backwards breaking so we have to do it when we next rev the index version.

 

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