Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-20260

New indexes should bump their Collection's minimum SnapshotName

    • Type: Icon: Bug Bug
    • Resolution: Done
    • Priority: Icon: Major - P3 Major - P3
    • 3.1.9
    • Affects Version/s: 3.1.7
    • Component/s: Querying
    • None
    • Fully Compatible
    • ALL
    • Hide

      jstest attached.

      Show
      jstest attached.
    • Quint 9 09/18/15

      This is a temporary solution to ensure that indexes created with w:majority are guaranteed to be usable to a read using majority readConcern level. Currently w:majority only waits for the OpTime and does not wait for the SnapshotName set on the Client. This means that it is possible for an index to be in the committed snapshot but not usable to queries since they are using a too old SnapshotName. The changes for this ticket will be made unnessesary once we complete the work of reunifying OpTime and SnapshotName for SERVER-20439.

      Original title: Running count with readConcern majority and a hint errors

      Original description:
      When running a count with a hint and readConcern majority, the command fails with planner returned bad hint.

      Here is the dbCommand object:

      {
              "count" : "jstests_hint1",
              "query" : { 
                  "live" : true,
                  "ts" : { 
                      "$lt" : ISODate("2009-02-08T18:55:08.272Z")
                  },  
                  "cls" : "entry",
                  "verticals" : "alleyinsider"
              },  
              "hint" : { 
                  "ts" : 1 
              },  
              "fields" : { 
              },  
              "readConcern" : { 
                  "level" : "majority"
              }   
          }
      

      And the log output with the error.

      m31000| 2015-09-02T11:14:05.543-0400 I COMMAND  [conn1] command test.jstests_hint1 command: count { count: "jstests_hint1", query: { live: true, ts: { $lt: new Date(1234119308272) }, cls: "entry", verticals: "alleyinsider" }, hint: { ts: 1.0 }, fields: {}, readConcern: { level: "majority" } } ntoreturn:1 ntoskip:0 keyUpdates:0 writeConflicts:0 numYields:0 reslen:273 locks:{ Global: { acquireCount: { r: 2 } }, Database: { acquireCount: { r: 1 } }, Collection: { acquireCount: { r: 1 } } } protocol:op_command 1919ms
      {
      	"waitedMS" : NumberLong(945),
      	"ok" : 0,
      	"errmsg" : "error processing query: ns=test.jstests_hint1Tree: $and\n    cls == \"entry\"\n    live == true\n    verticals == \"alleyinsider\"\n    ts $lt new Date(1234119308272)\nSort: {}\nProj: {}\n planner returned error: bad hint",
      	"code" : 2
      }
      

            Assignee:
            mathias@mongodb.com Mathias Stearn
            Reporter:
            michael.grundy Michael Grundy
            Votes:
            0 Vote for this issue
            Watchers:
            9 Start watching this issue

              Created:
              Updated:
              Resolved: