runAggregate should be refactored so that locking isn't so confusing

XMLWordPrintableJSON

    • Type: Task
    • Resolution: Unresolved
    • Priority: Major - P3
    • None
    • Affects Version/s: None
    • Component/s: None
    • None
    • Query Execution
    • None
    • None
    • None
    • None
    • None
    • None
    • None

      My particular angle of motivation on the refactor is from SERVER-67424 wherein I encountered the following problem:

      "It appears that we modify read concern settings (prepared conflict) in DocumentSourceWriter. The problem with this is that if the high level code has a AutoGetLockFree*, we've already got a storage snapshot open: read concern is normally manipulated in the AutoGet* or earlier layers. It works today because we happen not to hold AutoGet* across runAggregate's use of DocumentSourceWriter. I was trying to hold locks across this, to hold a lock across registration of CursorManager::registerCursor for concurrency control with replication rollback."

      Locking uncertainty in runAggregate hinders development: it's very confusing.

            Assignee:
            [DO NOT USE] Backlog - Query Execution
            Reporter:
            Dianna Hohensee (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated: