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

Cursor leak in aggregation that requires merging on shard

    • Type: Icon: Bug Bug
    • Resolution: Fixed
    • Priority: Icon: Major - P3 Major - P3
    • 4.4.19, 5.0.15, 6.0.4, 6.2.0-rc0
    • Affects Version/s: None
    • Component/s: None
    • None
    • Fully Compatible
    • ALL
    • v6.1, v6.0, v5.0, v4.4
    • Hide

      ./buildscripts/resmoke.py run --storageEngine=wiredTiger --storageEngineCacheSizeGB=.50 --suite=sharding jstests/sharding/repro-server-65259.js --log=file
      0001-Repro-SERVER-65259.patch

      Show
      ./buildscripts/resmoke.py run --storageEngine=wiredTiger --storageEngineCacheSizeGB=.50 --suite=sharding jstests/sharding/repro-server-65259.js --log=file 0001-Repro-SERVER-65259.patch
    • QE 2022-09-19, QE 2022-10-03
    • 4

      Consider an aggregation that requires merging on a shard. First, mongos opens the split cursors on the shards. Later, in order to establish the merge cursor, dispatchMergingPipeline is called and the split cursors ownership is transferred to it. There, sharded_agg_helpers::addMergeCursorsSource will transfer the split cursors ownership to the merge pipeline. Finally, the merge cursor will be established. However, if this fails (for instance if the shard is in the middle of a migration critical section), 'storePossibleCursor' will return here and then the split cursors ownership is dismissed from the mergePipeline. However, because the merge cursor was not really established, the shard did not take ownership of those cursors either, so they are leaked.

            Assignee:
            mickey.winters@mongodb.com Mickey Winters
            Reporter:
            jordi.serra-torrens@mongodb.com Jordi Serra Torrens
            Votes:
            0 Vote for this issue
            Watchers:
            8 Start watching this issue

              Created:
              Updated:
              Resolved: