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

FSM threads race in secondary_reads_with_catalog_changes.js

    XMLWordPrintableJSON

Details

    • Bug
    • Status: Closed
    • Major - P3
    • Resolution: Fixed
    • None
    • 4.9.0
    • None
    • None
    • Fully Compatible
    • ALL
    • Execution Team 2021-01-25
    • 12

    Description

      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.

      Attachments

        Issue Links

          Activity

            People

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

              Dates

                Created:
                Updated:
                Resolved: