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

XMLWordPrintableJSON

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

      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
              Reporter:
              Gregory Wlodarek
              Votes:
              0 Vote for this issue
              Watchers:
              10 Start watching this issue

                Created:
                Updated: