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

Yielding locks with uncommitted prepared transactions can cause validate to update the fast count incorrectly

XMLWordPrintableJSON

    • Type: Icon: Bug Bug
    • Resolution: Unresolved
    • Priority: Icon: Major - P3 Major - P3
    • None
    • Affects Version/s: None
    • Component/s: None
    • None
    • Storage Execution
    • ALL

      As seen in SERVER-94825, uncommitted fast count updates leak out to other concurrent operations. Initially, this was harmless as validation obtains an exclusive lock on the collection, so it should be serialized with CRUD operations. However, uncommitted prepared transactions yield locks when a node steps down. This allows validation to run and incorrectly adjust the fast count.

      Could we make fast count updates ACID-compliant? It doesn't seem right to have validation skip updating fast count if there are uncommitted prepared transactions. It seems like a slippery slope if there are more ways we can get into this scenario.

            Assignee:
            Unassigned Unassigned
            Reporter:
            gregory.wlodarek@mongodb.com Gregory Wlodarek
            Votes:
            0 Vote for this issue
            Watchers:
            9 Start watching this issue

              Created:
              Updated: