[SERVER-20261] Planner unable to find index for $geoNear query with readConcern majority Created: 02/Sep/15  Updated: 23/Feb/18  Resolved: 02/Sep/15

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

Type: Bug Priority: Major - P3
Reporter: Michael Grundy Assignee: Unassigned
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File geonearreadconcern.js    
Issue Links:
Duplicate
duplicates SERVER-20260 New indexes should bump their Collect... Closed
Related
Operating System: ALL
Steps To Reproduce:

jstest attached

Participants:

 Description   

Running a $geoNear on a 2d index with a readConcern majority will fail with the following error:

m31000| 2015-09-02T11:50:41.740-0400 I COMMAND  [conn1] command test.geo2 command: count { count: "geo2", query: { loc: { $geoNear: [ 50.0, 50.0 ] } }, fields: {}, limit: 100.0, readConcern: { level: "majority" } } ntoreturn:1 ntoskip:0 keyUpdates:0 writeConflicts:0 numYields:0 reslen:242 locks:{ Global: { acquireCount: { r: 2 } }, Database: { acquireCount: { r: 1 } }, Collection: { acquireCount: { r: 1 } } } protocol:op_command 1204ms
{
	"waitedMS" : NumberLong(230),
	"ok" : 0,
	"errmsg" : "error processing query: ns=test.geo2Tree: GEONEAR  field=loc maxdist=1.79769e+308 isNearSphere=0\nSort: {}\nProj: {}\n planner returned error: unable to find index for $geoNear query",
	"code" : 2
}



 Comments   
Comment by Michael Grundy [ 02/Sep/15 ]

Duplicate of SERVER-20260

Comment by Michael Grundy [ 02/Sep/15 ]

Still fails with w:majority on the index build.

Comment by Eric Milkie [ 02/Sep/15 ]

Ah, for this one you must pair read level majority reads with w:majority writes. In this case, I think it will fix the test if you do w:majority on the index build.

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