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

FSM threads race in secondary_reads_with_catalog_changes.js

    • Type: Icon: Bug Bug
    • Resolution: Fixed
    • Priority: Icon: Major - P3 Major - P3
    • 4.9.0
    • Affects Version/s: None
    • Component/s: None
    • Labels:
      None
    • Fully Compatible
    • ALL
    • Execution Team 2021-01-25
    • 12

      In this test, after SERVER-50610, the logic is roughly:

      • thread 0 always does inserts (with implicit createCollection) and create index on field x
      • All other threads do one of dropIndex, dropCollection, or scan index x (retry if index x not there because we assume thread 0 will create an index eventually)

      However, if thread 0 completes before others, all other threads could hang if the index is dropped again after.

      I think maybe we could make the dropIndex thread to always recreate one after dropping the index so we don't rely on tid:0 being there to create the index. In other words, we probably should never have dependencies between threads in FSM because some of them might finish before others.

            Assignee:
            louis.williams@mongodb.com Louis Williams
            Reporter:
            lingzhi.deng@mongodb.com Lingzhi Deng
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: