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

check if our semantics on getlasterror w:<n> are consistent on a series of write operations

    • Type: Icon: Bug Bug
    • Resolution: Done
    • Priority: Icon: Major - P3 Major - P3
    • None
    • Affects Version/s: 2.4.4
    • Component/s: Replication
    • None
    • ALL

      This is sort of a QA and design question – and if found to be wrong then woudl be a bug.

      Some users send a series of writes (w1, w2, w3, w4, w5, ..., w n) (on one connection) to a single replica set, and then after the series, call

      { getLastError:1, w:3 }

      for example. The assumption by the user is that when this is acknowledges, all writes through wn are propogated, including earlier writes like w5.

      However, suppose the write w n was a "no-op", such as

      db.foo.remove( { _id : "DNE" } ) // assume there is no "DNE" in the collection...
      

      or

      db.foo.update( { _id : "DNE" } , ... )
      

      In these cases wn is not placed in the oplog on the primary.

      A couple of questions:

      (1) If after w n I call getLastError with w=3 (or majority etc.), am I assured w2 and the others have propogated?

      Based on a simple test (below), it appears the the answer is yes. So perhaps all is fine.

      (2) What about sharded? (2a) What is the contract for sharded? (2b) And what happens, and is it correct?

      x:PRIMARY> // this is a one member replica set
      x:PRIMARY> db.foo.insert({})
      x:PRIMARY> db.foo.remove({x:3333})  // this does not appear in the oplog -- perhaps that is a good thing
      x:PRIMARY> db.getLastError(2)       // hangs forever, as one would want, indicating question  #1 behaves "nicely"
      

            Assignee:
            milkie@mongodb.com Eric Milkie
            Reporter:
            dwight@mongodb.com Dwight Merriman
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated:
              Resolved: